<shadows>
marex: in that, clk_get_rate() returns 0
pitillo has quit [Ping timeout: 252 seconds]
K900 has quit [Remote host closed the connection]
K900 has joined #u-boot
vardhan has quit [Quit: Leaving]
<shadows>
marex: oh... maybe I don't have the right 'bootph-pre-ram' hints; because it seems to fail in SPL but then when U-Boot Main exec's clk_get_by_index() returns 0 and clk_get_rate() returns 24'000'000
<shadows>
or else there's some side effect of my setting plat->clock
<shadows>
I added bootph-pre-ram to every node in jh7110.dtsi and jh7110-common.dtsi and still it's this situation where SPL clk_get_by_index() as you quoted returns -19 then clk_get_rate() returns, and I've set plat->clock=24000000 just to get on with it but at U-Boot Main on the second invocation clk_get_by_index() returns 0 and clk_get_rate() returns 24000000
warpme has joined #u-boot
ldevulder has joined #u-boot
LainIwakura has joined #u-boot
monstr has quit [Ping timeout: 252 seconds]
LainIwakura has quit [Client Quit]
LainIwakura has joined #u-boot
LainIwakura has quit [Client Quit]
LainIwakura has joined #u-boot
<marex>
shadows: git grep 19 include | grep errno
<marex>
the -19 is ENODEV , no ?
<marex>
shadows: maybe you need clock driver in SPL ?
mripard has joined #u-boot
Hypfer6 has quit [Ping timeout: 244 seconds]
clamor has quit [Ping timeout: 260 seconds]
<shadows>
marex: config option? or as in adding C code... the config has CONFIG_SPL_SYS_NS16550_SERIAL=n since conflict SPL_DM_SERIAL=y
Hypfer6 has joined #u-boot
clamor has joined #u-boot
haritz has joined #u-boot
haritz has joined #u-boot
haritz has quit [Changing host]
goliath has quit [Quit: SIGSEGV]
<marex>
shadows: hum ... can you fit DM clock and DM serial into SPL ?
<marex>
if not, then you might have to move clock-frequency = < ... > into -u-boot.dtsi
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
mtoy has quit [*.net *.split]
LainIwakura has quit [Quit: Client closed]
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #u-boot
LainIwakura has joined #u-boot
frieder has quit [Remote host closed the connection]
jfsimon has quit [Remote host closed the connection]
goliath has joined #u-boot
jfsimon has joined #u-boot
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #u-boot
iprusov has quit [Ping timeout: 252 seconds]
enok has joined #u-boot
Guest313 has joined #u-boot
enok71 has joined #u-boot
enok has quit [Ping timeout: 276 seconds]
enok71 is now known as enok
<Guest313>
Hello! I currently use u-boot on a generic x86 intel board (u-boot built as efi application). Booting a kernel with an initrd is working without any problems. Unfortunately i can only use one cpu core. With grub all cores are available. I think there is a problem with the acpi tables and u-boot. Does anyone know what i have to do to enable all
<Guest313>
cores with u-boot?
<xypron>
Guest313: U-Boot only uses 1 core. The others are brought up by the OS
<xypron>
Guest313: What do you mean by generic board? Do you use QEMU?
<xypron>
U-Boot can pass through ACPI tables from the original firmware or create some itself. What defconfig are you using?
ldevulder has quit [Ping timeout: 276 seconds]
<Guest313>
xypron: It is a board with an i3 10th gen cpu - I am using the "efi-x86_app64_defconfig" config
<Guest313>
xypron: I also tried to enable "CONFIG_SMP" - Without any changes
<Guest313>
xypron: dmesg prints "smpboot: Boot CPU (id 0) not listed by BIOS" / "smpboot: Allowing 1 CPUs, 0 hotplug CPUs" / "smpboot: SMP disabled"
<Guest313>
xypron: How can i pass through the ACPI tables?
jfsimon has quit [Remote host closed the connection]
Guest313 has quit [Quit: Client closed]
warpme has joined #u-boot
ungeskriptet has quit [Remote host closed the connection]
<warpme>
guys: is there way to "easy" configure/ask uboot in extlinux.conf file to load dt overlay?
<xypron>
Guest313: efi-x86_app64_defconfig generates a minimum ACPI table and has no knowledge of the CPU.
jfsimon has joined #u-boot
dsimic has quit [Ping timeout: 244 seconds]
dsimic has joined #u-boot
ungeskriptet has joined #u-boot
LainIwakura has quit [Quit: Client closed]
Guest73 has joined #u-boot
Guest73 has quit [Client Quit]
Guest313 has joined #u-boot
mripard has quit [Quit: WeeChat 4.6.1]
<Guest313>
xypron: How can i change this? Is there no generic implementation? (like grub)
LainIwakura has joined #u-boot
jfsimon has quit [Remote host closed the connection]
mckoan is now known as mckoan|away
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Guest313 has quit [Quit: Client closed]
jfsimon has joined #u-boot
LainIwakura has quit [Ping timeout: 240 seconds]
jfsimon has quit [Remote host closed the connection]
blackbox has joined #u-boot
jfsimon has joined #u-boot
LainIwakura has joined #u-boot
ikarso has quit [Quit: Connection closed for inactivity]
jfsimon has quit [Remote host closed the connection]
<xypron>
Guest313: You would have to paa through ACPI and SMBIOS tables. Maybe ask sjg1
warpme has joined #u-boot
jfsimon has joined #u-boot
LainIwakura has quit [Ping timeout: 240 seconds]
<sjg1>
Guest313: Actually on x86 U-Boot brings up all cores, so long as CONFIG_SMP is enabled, which it is not with EFI. But I suspect that your UEFI firmware has already done this. Which U-Boot tree are you using? The tree at sjg.u-boot.org has better EFI-app support. See also https://www.youtube.com/watch?v=hte60f7I9j4
<Tartarus>
But please note that's Simon's personal downstream tree and not official.
LainIwakura has joined #u-boot
mmu_man has quit [Ping timeout: 265 seconds]
mmu_man has joined #u-boot
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #u-boot
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Guest313 has joined #u-boot
Guest313 has quit [Client Quit]
Poltawer has joined #u-boot
Guest313 has joined #u-boot
<Guest313>
sjg1: I am using v2025.01 - So the CONFIG_SMP has no function in efi app mode?
<Guest313>
sjg1: I know the video and already adapted some of the functions for my use case :-)
Guest313 has quit [Quit: Client closed]
prabhakalad has quit [Ping timeout: 245 seconds]
<sjg1>
Guest313: That's right. In EFI mode U-Boot is not responsible for setting up the ACPI tables. EFI handover was added in "9121737455c Add EFI handover support to bootm". As Tom says, this is my tree
<sjg1>
Guest313: Please send patches if you are able to improve it!
prabhakalad has joined #u-boot
mmu_man has quit [Ping timeout: 252 seconds]
mmu_man has joined #u-boot
<Tartarus>
xypron: That initrd related fix, do you want that in rc1 or is it OK to wait?
<shadows>
marex: CONFIG_SPL_DM_SERIAL and CONFIG_SPL_CLK are both set, what is the config name for "DM clock ... (in SPL)" ? that you refer to
<shadows>
I do find CONFIG_SPL_CLK_JH7110 "This enables SPL DM support for clock driver in JH7110."
<shadows>
apparently with no consumers in the source tree though ?
clamor has quit [Read error: Connection reset by peer]
rvalue- has joined #u-boot
rvalue has quit [Ping timeout: 252 seconds]
<shadows>
it selects SPL_CLK and SPL_CLK_CCF
blackbox has joined #u-boot
rvalue- is now known as rvalue
<xypron>
Tartarus: I did not have time to review the patch, yet. Specifically I am worried about missing tests.
<shadows>
symbol DM_CLK is something I think unrelated it is about networking
<shadows>
marex: clock-frequency = < ... > is already in -u-boot.dtsi and there should not be a problem to fit more code size into SPL on JH7110. Was this just not implemented? Is it already enabled but debug UART is conflicting? I don't know what exactly to search for here
<shadows>
I'm trying to remove the need for -u-boot.dtsi so I do want to know why this happens
blackbox has quit [Quit: WeeChat 4.6.2]
LainIwakura has quit [Ping timeout: 240 seconds]
<shadows>
xypron: do you have any guess about this, remove "clock-frequency = 24000000;" from &uart0 node at arch/riscv/dts/jh7110-common.dtsi and U-Boot SPL fails at drivers/serial/ns16550.c:ns16550_serial_of_to_plat() on call to clk_get_by_index() with result -19 (-ENODEV), then code path is to `return -EINVAL` which makes the boot fail
<Tartarus>
xypron: ok, thanks
<shadows>
however replacing that `return -EINVAL` with some close-enough clock value as in `plat->clock = 24000001UL;` gets us through the -ENODEV at SPL phase and the next time around in U-Boot Main the clock device is found and sets the correct 24MHz clock value from device-tree
KREYREN has joined #u-boot
<shadows>
is it a bug? is it missing JH7110 platform code? is it some config option that enables code which results in -ENODEV for that call from SPL (and later is successful at U-Boot Main) ?
Jones42 has quit [Ping timeout: 244 seconds]
umbramalison has quit [Quit: %So long and thanks for all the fish%]
umbramalison has joined #u-boot
LainIwakura has joined #u-boot
<Kwiboo>
shadows: as marex already said, for SPL set clock-frequency prop in -u-boot.dtsi or ensure your clk driver is compiled, included in SPL and can return correct rate, you also need to include any related clock nodes in the SPL control FDT, e.g. check "dtc -I dtb -O dts spl/u-boot-spl.dtb" include all relevants DT nodes
<shadows>
thank you, looking now
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #u-boot
jfsimon has quit [Remote host closed the connection]
<shadows>
the difficulty for me is I understand what you are saying, but I don't know how to actually do this. There's a disconnect between "make sure everything is there" and knowing _what_ I am supposed to be searching for to find it
<shadows>
"all relavent DT nodes" is what, in this case? because I just know that the frequency is supposed to be 24MHz which in hex is 0x16e3600, and I do search this value in the "dtc -I dtb -O dts spl/u-boot-spl.dtb" output but it doesn't have any meaning I don't understand what I'm looking at
<shadows>
and how do you check that "clk driver is compiled, included in SPL and can return correct rate" ?
<Kwiboo>
shadows: looking at the code, your issue could possible be related to clock name change (without digging too much into what was changed), the uart0 core clock seem to use a parent named "oscillator" (node name of osc clock), however that cloc use: clock-output-names = "osc", so new name may be "osc" instead of "oscillator" as used in clk-jh7110.c
<shadows>
thanks for looking at that
<shadows>
should I try changing and testing? from what to what and where
<shadows>
curious that it would work in U-Boot Main payload though
m5zs7k has quit [Ping timeout: 252 seconds]
m5zs7k has joined #u-boot
<Kwiboo>
shadows: I suggest you try to keep the clock-frequency = <24000000> in the -u-boot.dtsi file if you do not know how to digg in and fully debug this issue, any reason you want/need to remove the clock-frequency prop from the u-boot specific dtsi file? it is there to help u-boot resolve the uart0 clk rate without a need to involve any clk driver
<shadows>
Kwiboo: part of an effort to upstream as many things as can be to Linux, away from -u-boot.dtsi overrides, and the comment I got from Emil on LKML was that it is not needed in &uart0 node (at least in Linux). For JH7110 (U-Boot visionfive2 board target) multi-targets we're selecting devicetree based on EEPROM content for a variety of different JH7110 CPU boards based around StarFive VisionFive2 reference
<shadows>
design
<shadows>
I just want to know why it doesn't work, as part of this process of moving away from having overrides
<shadows>
why it doesn't work in SPL*
<Kwiboo>
yep, fully agree, the clock-frequency is only needed for u-boot, hence it is in a -u-boot.dtsi file, typically to allow keeping SPL small in size and looking up the value from clock-frequency can be much faster than having to get a known static value (at compile time) from a clk driver at runtime
<shadows>
yes, and that is how it's been
<shadows>
but it should work? I mean, same code path works in U-Boot Main. What's preventing this from working in SPL too
<Kwiboo>
possible reasons: compile options and drivers included in SPL differs and something is missing or the control FDT used by SPL is missing nodes/properties that any drivers may need to fully load
<sjg1>
shadows: Kwiboo: This brings back memories from many years ago when I proposed a clock-frequency property for the UART. At the time a very wise person told me that it was a bad idea to do this in a bootloader and we should just implement the full clock driver in U-Boot and run all that code before we could even get a message shown. He was of course wrong :-)