[WIP] Testing #3
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Hi! I'll have a look at those patches tomorrow (it's 4AM in Europe right now) and currently testing another build. I've created #coreboot-porting on oftc.net so we could collaborate better on this project if you're interested. Mind giving some examples of USB3 docks not working? I'm typing this comment from latest coreboot build, USB3 dock in LG 27GP850 monitor (plugged into USB3 port) seem to work just fine. P.S: Update on iGPU situation: Reverted the patch, still crashing with VAAPI decoding. |
|
@ellyq here is the USB devices: Apparently it has some functionality, it's probably those "VIA" devices but nothing connected to them seems to work. The Ethernet port and audio jack are working fine by the way. Don't jinx it !!! I've being experiencing some freezes, couldn't pinpoint the issue yet most of time they are pretty random and usually when i'm AFK. Nothing on Windows tho, so you are probably on the right track |
ellyq
pushed a commit
that referenced
this pull request
Oct 12, 2023
During phase 1 of the resource allocation we gather all the size
requirements. Starting from the leafs of our devicetree, we cal-
culate the requirements per bus, until we reach the resource do-
main.
However, because alignment plays a role, we can't just accumulate
the sizes of all resources on a bus. Instead, we already sort all
the resources per bus to predict their relative placement, inclu-
ding alignment gaps. Then, phase 2 has to perform the final allo-
cations with the exact same relative placement.
This patch introduces a very simple mechanism to avoid repeating
all the calculations: In phase 1, we note the relative `base` of
each resource on a bus. And after we allocated all the resources
directly below the domain in phase 2, we add the absolute `base`
of bridge resources to the relative `base` of child resources.
This saves most of the computational complexity in phase 2. How-
ever, with a shallow devicetree with most devices directly below
the domain, this won't have a measurable impact.
Example after phase 1:
domain
|
`-- bridge #0
| res #0, base 0x000000 (relative),
| size 12M, align 8M
|
|-- device #0
| res #1, base 0x800000 (relative),
| size 4M, align 4M
|
`-- bridge #1
| res #2, base 0x000000 (relative),
| size 8M, align 8M
|
`-- device #1
res #3, base 0x000000 (relative),
size 8M, align 8M
After phase 2 allocation at the domain level (assuming res #0 got
0xa000000 assigned):
domain
|
`-- bridge #0
| res #0, base 0xa000000 (absolute),
| size 12M, align 8M
|
|-- device #0
| res #1, base 0x800000 (relative),
| size 4M, align 4M
|
`-- bridge #1
| res #2, base 0x000000 (relative),
| size 8M, align 8M
|
`-- device #1
res #3, base 0x000000 (relative),
size 8M, align 8M
Now, all we need to do is to add the `base` of bridge resources
recursively. Starting with resources on the bus below bridge #0:
domain
|
`-- bridge #0
| res #0, base 0xa000000 (absolute),
| size 12M, align 8M
|
|-- device #0
| res #1, base 0xa800000 (absolute),
| size 4M, align 4M
|
`-- bridge #1
| res #2, base 0xa000000 (absolute),
| size 8M, align 8M
|
`-- device #1
res #3, base 0x000000 (relative),
size 8M, align 8M
And finally for resources on the bus below bridge #1:
domain
|
`-- bridge #0
| res #0, base 0xa000000 (absolute),
| size 12M, align 8M
|
|-- device #0
| res #1, base 0xa800000 (absolute),
| size 4M, align 4M
|
`-- bridge #1
| res #2, base 0xa000000 (absolute),
| size 8M, align 8M
|
`-- device #1
res #3, base 0xa000000 (absolute),
size 8M, align 8M
Change-Id: I70c700318a85f6760f27597730bc9c9a86dbe6b3
Signed-off-by: Nico Huber <[email protected]>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65420
Reviewed-by: Lean Sheng Tan <[email protected]>
Reviewed-by: Arthur Heymans <[email protected]>
Tested-by: build bot (Jenkins) <[email protected]>
Reviewed-by: Felix Singer <[email protected]>
ellyq
pushed a commit
that referenced
this pull request
Oct 12, 2023
x86 pre-memory stages do not support the `.data` section and as a
result developers are required to include runtime initialization code
instead of relying on C global variable definition.
To illustrate the impact of this lack of `.data` section support, here
are two limitations I personally ran into:
1. The inclusion of libgfxinit in romstage for Raptor Lake has
required some changes in libgfxinit to ensure data is initialized at
runtime. In addition, we had to manually map some `.data` symbols in
the `_bss` region.
2. CBFS cache is currently not supported in pre-memory stages and
enabling it would require to add an initialization function and
find a generic spot to call it.
Other platforms do not have that limitation. Hence, resolving it would
help to align code and reduce compilation based restriction (cf. the
use of `ENV_HAS_DATA_SECTION` compilation flag in various places of
coreboot code).
We identified three cases to consider:
1. eXecute-In-Place pre-memory stages
- code is in SPINOR
- data is also stored in SPINOR but must be linked in Cache-As-RAM
and copied there at runtime
2. `bootblock` stage is a bit different as it uses Cache-As-Ram but
the memory mapping and its entry code different
3. pre-memory stages loaded in and executed from
Cache-As-RAM (cf. `CONFIG_NO_XIP_EARLY_STAGES`).
eXecute-In-Place pre-memory stages (#1) require the creation of a new
ELF segment as the code segment Virtual Memory Address and Load Memory
Address are identical but the data needs to be linked in
cache-As-RAM (VMA) but to be stored right after the code (LMA).
Here is the output `readelf --segments` on a `romstage.debug` ELF
binary.
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000080 0x02000000 0x02000000 0x21960 0x21960 R E 0x20
LOAD 0x0219e0 0xfefb1640 0x02021960 0x00018 0x00018 RW 0x4
Section to Segment mapping:
Segment Sections...
00 .text
01 .data
Segment 0 `VirtAddr` and `PhysAddr` are at the same address while they
are totally different for the Segment 1 holding the `.data`
section. Since we need the data section `VirtAddr` to be in the
Cache-As-Ram and its `PhysAddr` right after the `.text` section, the
use of a new segment is mandatory.
`bootblock` (#2) also uses this new segment to store the data right
after the code and load it to Cache-As-RAM at runtime. However, the
code involved is different.
Not eXecute-In-Place pre-memory stages (#3) do not really need any
special work other than enabling a data section as the code and data
VMA / LMA translation vector is the same.
TEST=#1 and #2 verified on rex and qemu 32 and 64 bits:
- The `bootblock.debug`, `romstage.debug` and
`verstage.debug` all have data stored at the end of the `.text`
section and code to copy the data content to the Cache-As-RAM.
- The CBFS stages included in the final image has not improperly
relocated any of the `.data` section symbol.
- Test purposes global data symbols we added in bootblock,
romstage and verstage are properly accessible at runtime
#3: for "Intel Apollolake DDR3 RVP1" board, we verified that the
generated romstage ELF includes a .data section similarly to a
regular memory enabled stage.
Change-Id: I030407fcc72776e59def476daa5b86ad0495debe
Signed-off-by: Jeremy Compostella <[email protected]>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77289
Tested-by: build bot (Jenkins) <[email protected]>
Reviewed-by: Arthur Heymans <[email protected]>
ellyq
pushed a commit
that referenced
this pull request
Jul 10, 2024
This also changes how debug messages will be printed. I focused on reducing clutter on the screen and made the style of the messages consistent. Before: azalia_audio: Initializing codec #5 codec not ready. azalia_audio: Initializing codec #4 codec not valid. azalia_audio: Initializing codec #3 azalia_audio: viddid: ffffffff azalia_audio: verb_size: 4 azalia_audio: verb loaded. After: azalia_audio: codec #5 not ready azalia_audio: codec #4 not valid azalia_audio: initializing codec #3... azalia_audio: - vendor/device id: 0xffffffff azalia_audio: - verb size: 4 azalia_audio: - verb loaded Change-Id: I92b6d184abccdbe0e1bfce98a2c959a97a618a29 Signed-off-by: Nicholas Sudsgaard <[email protected]> Reviewed-on: https://review.coreboot.org/c/coreboot/+/80332 Reviewed-by: Nico Huber <[email protected]> Reviewed-by: Felix Singer <[email protected]> Tested-by: build bot (Jenkins) <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
@ellyq First of all, thanks for all the hard work. We could get this far if it was not for you. I'm speaking in the name of a small, but very enthusiast folks.
We've run some test this weekend and your build definitely brought more efficiency to the table. We are seeing something around 10~15 W on high load (sintetic benchmarks)
Our first goal is to port all fixes for the quirks that this board has on the original firmware. Second, have the ability to set custom memory profiles. We had a look on coreboot-configurator but couldn't wrap our heads on how to get it running. It's throwing this error:
nvramtool: CMOS option table not found in coreboot table. Apparently, the coreboot installed on this system was built without selecting CONFIG_USE_OPTION_TABLE.We've also built nvramtool from source and it throws the same error.
As we couldn't get coreboot-configurator going we decided to hardcode some parameters, I left some comments in the code with our attempts. We are assuming there a issue selecting the customXmpProfile, as per your code it seems xmp1 is also not working and some issue with SA/Uncore when we set voltage (offset/voltage)
There were also some reports on USB 3.0 hub (docks) not working - Even on latest build.
We would like to help more, but don't have much expertise on how to troubleshoot/debug coreboot builds. Let us know what are your thoughts and how can we help you more (maybe a coreboot masterclass :P ?)