On Mon, Dec 18, 2017 at 2:10 PM, Jonathan Neuschäfer
On Mon, Dec 18, 2017 at 01:02:38PM +0000, Luke Kenneth Casson
> On Mon, Dec 18, 2017 at 12:40 PM, Jonathan Neuschäfer <j.neuschaefer(a)gmx.net>
> > That's good, because RAM init can be quite board specific.
> i've never dealt with anything other than SoCs, so i'm used to code
> (in u-boot) which probes the DDR3 interface, does all the
> initialisation(s), cranks the memory up to a 200mhz (or other set bus
> speed) and off it goes. some of the init stuff i've seen even does
> speed grading testing.
The way coreboot on newer chromebooks with soldered-on RAM chips usually
does it, is this:
1. It reads a few GPIO to calulate the "board ID"
2. It selects the right block of information, that's either compiled in
or loaded from CBFS (the coreboot file system). This can be either
direct settings for the DRAM controller, or the same data that would
be stored on SPD EEPROMs.
3. It applies these settings, which can also involve some
*silence for a little bit...*
... ew :) mind you, if you're going to make 1 million identical
product, and your company name is "google", that technique would work
I didn't know you could just "probe" the DDR3
interface, especially for
parameters like chip size. (But then again, I haven't done RAM init
yehyeh, rockchip released a *sigh* proprietary *sigh* binary i've
been reverse-engineering for several weeks, which i think is probably
supplied by the hard macro vendor (hence why rockchip can't release
its source code), and it does a huge amount of scanning of different
configurations, bus widths, block sizes and so on - it LITERALLY goes
through all possible permutations of the various different parameters,
and eventually it goes, "ah HA! that combination worked"
then it goes on to "training" of the DDR3 interface, working out the
best possible impedance for both the controller PHY *and* the DRAM
it's a hugely complex task and i was going through the disassembly,
in... awe of how comprehensive it has to be. automatic detection of
DDR2, DDR3, LPDDR3, dual banks of x16 ICs, quad banks of x8 ICs, dual
banks of x16 DDR3 RAM ICs which are actually two dies of x8.... i was
*fortunately* much of this code has made its way into the rk3288
u-boot source (GPLv2)... not that there's any explanation of it. it's
yet another "code dump" from yet another proprietary SoC fabless semi
company under NDA...
> > but coreboot can load U-Boot
> > as a payload on other architectures (it has not been tested on RISC-V).
> is there a config option to cut the compiled target down to an (appx)
> sub 16k raw binary?
Coreboot internally already uses multiple stages, called bootblock,
romstage (runs from "ROM" (flash), without DRAM), ramstage (runs from
DRAM). The bootblock should easily fit into 16 KiB and will chain-load
the next stage.
awesome! that would do that trick!
One thing that might cause problems: Coreboot boots from SPI flash
most boards, so CBFS-in-MMC is probably not a well tested configuration.
... it is in u-boot. the number of combinations it supports is...
comprehensive in the extreme.
(Why? Because x86 only boots from memory-mapped flash, which usually
means SPI these days, and parallel flash in the old days; The
Chromebooks' boot security scheme depends on being able to write-lock
part of the boot flash, I'm not sure if that's possible with eMMC; And,
of course, "it's the default thing that coreboot does", so it's easier
yyyeah all of which is telling me that, for a non-x86-style SoC,
starting from coreboot for a bootloader might not be the most sensible
thing to do. if on the other hand someone was designing a SoC that
was intended to be placed into a server rack or a mid-to-high-end
desktop system, such that it pretty much replicated (exactly) a
standard x86 setup (PCIe, DIMMs for memory etc. etc.) then coreboot
instead of u-boot sounds like it would be a pretty sensible strategy.
> > Only somewhat related: To ease early debugging, there should
not be too
> > many configuration steps (PLL setup, clock gating, power gating,
> > DMA-able RAM) in the way of having a UART.
> that's pretty much the definition of a SPI u-boot executable :)
Well, yes, all these things are doable, but what do you do when they
don't work and you have to debug them? An easy to initialize UART can
help a lot in this case.
yehyeh. oh have you seen daniel glisselquest's zipCPU? he wrote a
really cool UART driver that includes both UART *and* some form of
JTAG-like interface on it, which in theory you could actually use as a
bootloader. i was considering using it, by substituting an STM32F (or
even a $0.20 STM8S) for a passive NAND/NOR IC. that would have the
distinct advantage of being able to transform into a USB-to-UART, and
STM32F/STM8S ICs of course have their own on-board NAND FLASH... so
you can store the bootloader in *that*... theeennn... you could get
the STM EC to load more (if needed) from.. say... MMC, or Quad SPI, or
over USB, whatever you wanted.
and, the big advantage is: the STM32F072 is like $1.60, the STM8S003
is $0.20, pick your price-point, but more than that it's a *known
quantity*. no messing about, "eek did i get the design right, here,
of the boot ROM and the IC design right and and and" :)
> > And whatever is done, don't
> > go the x86 way of relying on EHCI debug!
> :) oh is that the one where you can hack into any x86 system just
> by plugging in a USB cable?
No, it's not that kind of debug interface (that's Intel DCI, and it's
not quite *that* drastic). EHCI Debug is a special mode of the EHCI
controller that makes it possible to use it without DMA. You can only
send small USB packets, but that's enough for simple logging.
My point is: EHCI Debug plus a compatible adapter (some Linux computer
in USB device mode, or FTDI FT232H, but not FT232R) is already a much
more complex setup than necessary when you could have a simple two-pin
tell me about it. the only embedded SoC i've ever heard of - Ingenic
(MIPS), ICubeCorp (proprietary), Freescale, TI, NXP, Allwinner,
Rockchip doesn't really matter who they are, not with a *single one of
them* do people do anything more complex than UART-based debugging
(early printk *always* goes to UARTs *NEVER* to a screen), and for
booting it's SPI, eMMC, NAND and possibly USB, with the sole exception
of the Freescale iMX6, which for some utterly bizarre reason actually
has UEFI partition format support in its boot ROM, and i believe they
also added native SATA boot support.
people who use PCs - and people who develop linux kernel drivers for
x86.. they just... they *really* don't Get It. not even linus
torvalds Gets It. he actually told the ARM linux kernel people to "go
away and come back with only one representative" when, in a room full
of 36 developers at the linux developer conference 10 years ago fully
50% of the people present represented completely disparate ARM
processor companies, the designs of which bore *absolutely no
relation* or connection to any of the others - including in many cases
the instruction set (armel, armhf.... etc.)