Re: [coreboot] Compile coreboot 4.3 for Pc Engines Alix2d3

[Andrey Korolyov]

On Mon, Mar 7, 2016 at 2:19 AM, Reto Rayen  wrote:
> Hi guys
>
> I tried now with the latest coreboot 4.3 to run the coreboot bios on a
> Alix2d3. But it always hangs after: «* DRAM Controller init done.». After
> this i do not see any further Output. Does anyone of you have a an idea what
> could be the issue?
>
> I added a ipxe Rom Image to the coreboot Rom. The layout is as follows:
>
> Name                           Offset     Type         Size
>
> cbfs master header             0x0        cbfs header  32
>
> fallback/romstage              0x80       stage        12404
>
> fallback/ramstage              0x3180     stage        69972
>
> fallback/payload               0x14340    payload      60882
>
> pci1106,3053.rom               0x23180    raw          81920
>
> config                         0x37200    raw          428
>
> revision                       0x37400    raw          602
>
> payload_config                 0x376c0    raw          1563
>
> payload_revision               0x37d40    raw          219
>
> vsa                            0x37e80    stage        57532
>
> (empty)                        0x45f80    null         236568
>
> bootblock                      0x7fbc0    bootblock    768
>
> The config file with the build Options can be found here:
>
> https://file.youngsolutions.ch/index.php/s/MrXbSGYdS5E8DsH
>
> Here a trace of the full Output:
>
> Setup throttling delays to proper mode
>
> Done cpuRegInit
>
> Ram1.00
>
> Ram2.00
> sdram_set_spd_register
>
> spd_read_byte dev 50 addr 15 returns ff
>
> Check DIMM 0
>
> Check DIMM 1
>
> spd_read_byte dev 51 returns 0xff
> Check DDR MAX
>
> spd_read_byte dev 50 addr 09 returns 0a
>
> spd_read_byte dev 51 returns 0xff
>
> AUTOSIZE DIMM 0
>
> Check present
>
> spd_read_byte dev 50 addr 02 returns 07
> MODBANKS
>
> spd_read_byte dev 50 addr 05 returns 01
> FIELDBANKS
>
> spd_read_byte dev 50 addr 11 returns 04
> SPDNUMROWS
>
> spd_read_byte dev 50 addr 03 returns 03
>
> spd_read_byte dev 50 addr 04 returns 0a
> SPDBANKDENSITY
>
> spd_read_byte dev 50 addr 1f returns 40
>
> DIMMSIZE
>
> BEFORT CTZ
>
> TEST DIMM SIZE>8
>
> PAGESIZE
>
> spd_read_byte dev 50 addr 04 returns 0a
>
> MAXCOLADDR
> > 12address test
>
> RDMSR CF07
>
> WRMSR CF07
>
> ALL DONE
>
> AUTOSIZE DIMM 1
>
> Check present
>
> spd_read_byte dev 51 returns 0xff
> set cas latency
>
> spd_read_byte dev 50 addr 12 returns 10
>
> spd_read_byte dev 50 addr 17 returns 3c
>
> spd_read_byte dev 50 addr 19 returns 4b
>
> spd_read_byte dev 51 returns 0xff
> set all latency
>
> spd_read_byte dev 50 addr 1e returns 28
>
> spd_read_byte dev 51 returns 0xff
>
> spd_read_byte dev 50 addr 1b returns 0f
>
> spd_read_byte dev 51 returns 0xff
>
> spd_read_byte dev 50 addr 1d returns 0f
>
> spd_read_byte dev 51 returns 0xff
>
> spd_read_byte dev 50 addr 1c returns 0a
>
> spd_read_byte dev 51 returns 0xff
>
> spd_read_byte dev 50 addr 2a returns 46
>
> spd_read_byte dev 51 returns 0xff
> set emrs
>
> spd_read_byte dev 50 addr 16 returns ff
>
> spd_read_byte dev 51 returns 0xff
> set ref rate
>
> spd_read_byte dev 50 addr 0c returns 3a
>
> spd_read_byte dev 51 returns 0xff
>
> Ram3
> DRAM controller init done.
>
> Gesendet von Mail für Windows 10

Hi Reto,

I noticed that a month and a half ago [0] on a very simular board and
it turned to be a romcc issue as it was suggested here in ML. Using
very old tree, I was able to boot the board, though there was (still
unsolved, blame to myself) issues with cbfs ELF execution when VSA
blob is presented. If you would try to use some pre-cbfs alix/geode
code you would see the same issue with ELF loader (both cases could be
dirty-hacked for feeding an appropriate beginning of the bios
payload). I barely checked the presence of the endless loop and have
done zero effort yet to research from where it comes and if it
possible to fix it without getting too deep in a romcc code.

0. https://www.coreboot.org/pipermail/coreboot/2016-January/080867.html