<Clamor>
gpio-gate-clock lacks an actual clock, isn't it?
<Clamor>
marex: I have a driver which has gpio gated clock and it requires the rate of that clock, the current driver version cannot provide clock rate
redbutton has quit [Server closed connection]
redbutton has joined #u-boot
prabhakarlad has quit [Quit: Client closed]
<zear>
hey guys
<marex>
Clamor: I think the renesas s4 ufs does get clock rate out of it
<marex>
zear: hi
<zear>
whom should I add as e-mail recipient to a patch that adds an ARM QorIQ LS10xx board? Neither checkpatch nor MAINTAINERS are helpful
<Clamor>
marex: your driver has no get rate api
<zear>
oddly, TARGET_BCMNS3 maintainer is listed as supporting the entire arch/arm/Kconfig
<umbramalison>
Hi need a nudge in the right direction. Custom board, AM5726, eth0 is wired directly to microchip LAN7801, connected to usb hub. All baked on the board. on PoR i get "Net:error: phy_id read failed\n Could not get PHY for ethernet@48484000: addr 0\n eth2: ethernet@48484000". I have no idea what PHY support is required?
<Sout_>
because it's a phy no? quick look at the data sheet. from the micro's point of view it's a phy. no?
<umbramalison>
Sout_ right fair point. so that infers CONFIG_PHY_SMSC?
<Sout_>
yes? (easy answer, is look a board that uses it and look at the config, and device tree)
ukky has quit [Quit: Rebooting...]
<umbramalison>
Sout_ yes, ok so if CONFIG_PHY_SMSC is the right option, then i should find some boards using it, and they should have a similar layout. Otherwise, i got it all wrong.
<Sout_>
yep, that is exactly what i did for our custom device.
ukky has joined #u-boot
<Tartarus>
xypron, apalos just want to make sure you both see "bootstd: Support for distro specific EFI folders"
thopiekar has quit [Ping timeout: 256 seconds]
deathcamel57 has joined #u-boot
vagrantc has joined #u-boot
thopiekar has joined #u-boot
thopiekar has quit [Read error: Connection reset by peer]
frieder has quit [Remote host closed the connection]
flom84 has quit [Ping timeout: 260 seconds]
Hypfer has quit [Server closed connection]
Hypfer has joined #u-boot
Jacmet_ has quit [Server closed connection]
Jacmet has joined #u-boot
robher has quit [Server closed connection]
robher has joined #u-boot
<xypron>
sjg1: Should we really check CONFIG_GENERATE_ACPI_TABLE in drivers/misc/qfw.c? Reading ACPI tables from QEMU in write_acpi_tables() does not really sound like generating them.
<xypron>
Tartarus: do we have a description which pathes are search for Kconfig fragments?
<xypron>
searched
<Tartarus>
doc/develop/board_best_practices.rst
ikarso has joined #u-boot
Clamor has quit [Read error: Connection reset by peer]
prabhakarlad has joined #u-boot
prabhakar has joined #u-boot
rfried has quit [Server closed connection]
rfried has joined #u-boot
gsz has quit [Ping timeout: 260 seconds]
zsoltiv_ has quit [Server closed connection]
zsoltiv_ has joined #u-boot
sakman has quit [Quit: Leaving]
rfs613 has quit [Server closed connection]
Clamor has joined #u-boot
rfs613 has joined #u-boot
Clamor has quit [Read error: Connection reset by peer]
GNUtoo has quit [Quit: leaving]
GNUtoo has joined #u-boot
sakman has joined #u-boot
persmule has quit [Remote host closed the connection]
GNUtoo has quit [Remote host closed the connection]
GNUtoo has joined #u-boot
persmule has joined #u-boot
deathcamel57 has quit [Remote host closed the connection]
deathcamel57 has joined #u-boot
xypron has quit [Ping timeout: 260 seconds]
xypron has joined #u-boot
xypron has quit [Changing host]
xypron has joined #u-boot
mmind00 has quit [Server closed connection]
mmind00 has joined #u-boot
ikarso has quit [Quit: Connection closed for inactivity]
redbrain has quit [Read error: Connection reset by peer]
redbrain has joined #u-boot
<sjg1>
xypron: Evil character after filename :-)
<sjg1>
xypron: Oh...QEMU is exceptionally weird. They won't take devicetree additions to make U-Boot SPL work
<sjg1>
xypron: It does have ACPI tables but they need to be converted and placed in memory
<xypron>
sjg1: What do you mean by converted?
<sjg1>
xypron: So I believe that code is actually needed and the use of that CONFIG is...well, somewhat correct
<xypron>
sjg1: isn't the fw interface loading ACPI tables to the desired address?
<sjg1>
xypron: You can see the code in write_acpi_tables() in that file
<sjg1>
xypron: and messing with them, yes. It isn't just loading them
<xypron>
sjg1: but why depend on GENERATE_ACPI_TABLE which is meant to mean that U-boot is generating and not a prior boot stage?
<sjg1>
xypron: I could write memcpy() in less than 250 lines of code
<sjg1>
xypron: Well because that is what is happening, right? Try just pointing to the tables..it won't work
<xypron>
sjg1: because virtio provides an interface that you have to talk to
<xypron>
sjg1: The point is simply what is CONFIG_GENERATE_ACPI_TABLES meant to signify?
<xypron>
sjg1: You changed lib/efi_loader/Makefile to use CONFIG_ACPI instead of CONFIG_GENERATE_ACPI_TABLES to mean that we have an ACPI table to publish
<xypron>
sjg1: In cmd/bootefi.c we use CONFIG_GENERATE_ACPI_TABLES to mean an ACPI table is available.
<xypron>
sjg1: in lib/smbios.c you seem to use CONFIG_GENERATE_ACPI_TABLES indicate presence of an ACPI table.
<xypron>
sjg1: 53e8e6f98679 ("efi: x86: Correct the condition for installing ACPI tables") confuses me.
naoki has joined #u-boot
<sjg1>
xypron: OK I see
<sjg1>
xypron: ACPI should mean that there are ACPI tables
<xypron>
sjg1: so cmd/bootefi.c and lib/smbios.c should change
<sjg1>
GENERATE_ACPI_TABLES should mean that U-Boot has to create them, not just point to them
<sjg1>
xypron: Yes I suppose so. The ACPI code changed at some point and the old meanings are still there
<xypron>
So do we need that symbol in the qfw driver? If yes, the description of the symbol should at least be improved.
<xypron>
sjg1: Tartarus requested a symbol indicating that QEMU's version of write_acpi_tables() is used.