Hacker News Reader

Comment by codedokode | Hacker News Reader

Why cannot UART address be fixed by a standard? Is there any merit in having UART at different addresses on different machines?

View on HN

>Is there any merit in having UART at different addresses on different machines?

Is there any advantage to encumbering the ISA by having a fixed memory address?

If what you need is a debug console, use SBI Debug Console Extension[0].

Otherwise, get the address from the device tree, or from the pointer you've been passed by the SPL, if you are the SBI or you run without SBI.

Note that, in the first place, you will be accessing the UART registers using a register as base + an offset.

0. https://github.com/riscv-non-isa/riscv-sbi-doc/blob/master/s...

> Is there any advantage to encumbering the ISA by having a fixed memory address?

The software becomes much simpler. No need to parse any device trees. When something changes (for example, 128-bit quantum memory becomes available), simply make revision 2 for standard and move device addresses to other place.

You can certainly make some RISC-V platform standard that fixes addresses if you like -- as the PC did by totally copying IBM's machines -- but people want to avoid that.

There was a large ecosystem of MS-DOS computers before the IBM PC took over that had very diverse hardware and depended on the BIOS for compatibility.

We lost a lot when we all had to copy IBM's 640k RAM limit and A20 bug. Other, earlier, MS DOS machines allowed more RAM than that e.g. DEC Rainbow supported 896k of RAM. With a suitable expansion card the Sanyo MBC-550 could make 960k of RAM available to MSDOS.

>No need to parse any device trees.

If you just use the UART address that has been passed directly in a register, there's no need to look at the device tree.

If the UART base address was fixed, you'd normally need to load this base address in a register yourself and offset the hardware registers of the UART from it.

Yet, the way it actually is, this non-fixed base address is already in a register; You need to do even less work.

The problem with this approach is that usually there are more devices that registers. And registers are needed for other purposes rather than constantly storing UART's base address.

What if you have no UARTs? Multiple UARTs?

You can reserve multiple addresses. 64-bit address space is not small. And even 32-bit address space is huge.

Only if you think of it in advance, when you fix the standard for where everything goes.

But how many UARTs should you allow for? 2? 16? 256? No matter what you choose, someone many want to build a system with more, and if you choose 256 (or more) then that's getting to be significant wasted address space for people who only have one UART.

All the more so for things that use a lot more address space than half a dozen control registers for a UART. What about 4k (3840x2560) x32 bit frame buffers? Those are 37.5 MB each. Some people want one. Some people want to drive a wall of monitors.

Much more flexible to let people configure their address space how they want and supply a devicetree in ROM / SPI flash etc.

you could - but you'd have to start defining other stuff like where physical DRAM starts, where other devices like timers, interrupt controllers etc live because they all get reported that way too

So why not reserve fixed addresses for everything? What is the merit of having devices located at different addresses?

For example, on IBM PC devices like keyboard or mouse or beeper had fixed addresses and it caused no issues.

and everyone who made add-in cards had to add jumpers so that they could choose I/O and interrupt addresses that didn't collide, it was a nightmare - PCI (and Nubus before it) solved those problems with forms of geographical addressing, that required meta-data somewhat equivalent to device trees.

RISC-V cores start their physical DRAM addresses at different addresses, some at 0, some at an offset close to 0, some way high. Some embedded systems might have SRAM at one address and DRAM at another - any device addresses have to work around that - if you hard code the UART address then you force people to choose where their memory blocks live, it likely also forces the address range in which other embedded devices live (interrupt controllers, timers etc). RISC-V specs define what the various registers look like, but not where they are (other than offsets wrt other registers of the same type).

Multi-vendor architectural specs like RISC-V are a careful balance between making sure that things work and leaving the design space free for innovation - RISC-V doesn't carry a lot of baggage from previous systems which is a great thing

Reply on news.ycombinator.com