gaston1980 has quit [Remote host closed the connection]
gaston1980 has joined #linux-sunxi
lkcl has joined #linux-sunxi
<warpme_>
smaeul: sorry for late replay (was a bit busy). My thinking was following (pls correct me where i'm wrong): even if various H6 boards I want to support with single u-boot binary are using pinctrl options - my needs from u-boot might be: do minimal enough just to load & get working kernel (cpu, ram, sd-card reader). Then kernel will load & use pointed in u-boot's boot.scr dtb to fully init all peripherals. So
<warpme_>
essentially minimal common part for all boards in u-boot might be: cpu, ram, sd-card. Rest peripherals will be done by kernel + dtb. If this is correct thinking - how I should set build target in u-boot (<board_name>_defconfig)?. Will it be enough to find xx_defconfig which handles ok in all my H6 boards just cpu/ram/sd-card init?
<mru>
if the same settings for ram and sd card work on all the boards, that's the simple solution
<smaeul>
warpme_: the u-boot binaries for various boards are already practically the same. the only hard question is "which device tree to pass to Linux"
<smaeul>
the suggestions I gave earlier were various ways to answer that question
<mru>
over here we use a small i2c eeprom containing a board id code
<smaeul>
mripard: I'm not sure how I can better explain the msgbox clock situation
<smaeul>
ATF uses the msgbox hardware to implement PSCI, even if Linux doesn't have the msgbox driver loaded
<smaeul>
(s/uses/will use/ to be pedantic)
<mripard>
then ATF should modify the DT to say so
<mripard>
I'm not saying that keeping the clock enabled is the wrong thing
<mripard>
I'm saying this is the wrong place to make that happen
<smaeul>
mripard: so if ATF modifies the DT appended to u-boot, how does that get to Linux, when Linux usually loads DTB off the disk?
<smaeul>
do I need to write code so u-boot can figure out which nodes in its DTB came from ATF, so it can make the same modifications to the one it passes to Linux
<KotCzarny>
isnt it the uboot that loads dtb?
<smaeul>
that sounds problematic, especially when u-boot no longer has the original copy of its DTB
<smaeul>
KotCzarny: there's a DTB appended to the u-boot binary, which is used internally (before running you boot.scr), and is also read by ATF
<KotCzarny>
no i mean that boot kernel line points to loaded dtb
<fALSO>
yo
<KotCzarny>
kernel itself uses it, no? as i havent seen any place where kernel loads dtb specifically from disk
<MoeIcenowy>
KotCzarny: kernel doesn't load files from disk
<KotCzarny>
exactly
<smaeul>
KotCzarny: you probably have a line like "load mmc 0:1 ${fdt_addr_r} dtbs/${version}/${fdtfile}" in your boot.scr
<MoeIcenowy>
because to load files you need an environment that can read FS
<KotCzarny>
yes, but it's done by uboot, not kernel
<MoeIcenowy>
for one situation, the code inside kernel loads DTB
<MoeIcenowy>
it's EFISTUB
<MoeIcenowy>
in which the stub runs in EFI environment, which has FS support
<smaeul>
KotCzarny: yes (and even EFISTUB calls into u-boot)
<MoeIcenowy>
but the stub should load it before really passing control to real kernel
<smaeul>
my point is that loading DTB off disk breaks mripard's idea of modifying the DTB in ATF
<KotCzarny>
so basically kernel just uses whatever uboot/atf prepares?
<smaeul>
KotCzarny: no
<KotCzarny>
kernel cant load from disk, because it's too late/early for device/disk access
<smaeul>
the kernel sees whatever u-boot passes it
<smaeul>
which may have come from disk, or may have come from the u-boot binary, and may have had modifications made to it, using u-boot's "fdt" command, or internally in u-boot's C code
<KotCzarny>
unless he talks about some overlay for dtb
<KotCzarny>
in which case, yeah
<megi>
I'd say patch kernel dtb in u-boot, since that's where the knowledge of whether arisc FW is loaded, and what kind of ATF is used resides, and it is also able to modify the DTB meant for the kernel
<smaeul>
oh, great, we have everyone on IRC at once :)
<smaeul>
maybe we can actually make some design decisions that I've been asking people about for TWO YEARS
<smaeul>
megi: how do you think u-boot knows if arisc FW is loaded?
<megi>
it loads it from FIT, no?
<smaeul>
it's just another loadable in the FIT image, copied to RAM by SPL
<smaeul>
yes, but the firmware is actually run by ATF, because ATF has to know which PSCI implementation to use
<megi>
ah u-boot doesn't start the ARISC, just loads the code to sram?
JohnDoe_71Rus has joined #linux-sunxi
<smaeul>
yes
<smaeul>
(so far) ARISC requires zero changes to actual u-boot code; the only thing changed is mksunxi_fit_atf.sh
<megi>
ATF doesn't run at the time when DTB for the kernel is loaded, or does it?
<megi>
so it can't patch it
<smaeul>
sort of? ATF is still loaded in RAM, but it only runs in response to a trap to EL3
<mripard>
smaeul: the same way it tells the kernel about simplefb or PSCI? it doesn't really matter though if it's u-boot's internal DTB or not
aloo_shu has joined #linux-sunxi
<mripard>
afaik you just give an address to U-Boot and it uses that
<mripard>
and it's the bootm code that modifies it
<mripard>
so the source doesn't really matter
<mripard>
only the address does
<smaeul>
how does the bootm code know how to modify it?
<smaeul>
or even if it should modify it?
<mripard>
are you asking in general or in your case?
<smaeul>
my case, I guess?
<mripard>
iirc, the SPL starts ATF, which then starts U-Boot right, and the ATF is the one making that decision
<mripard>
so why isn't ATF doing that DT editing before giving it to U-Boot?
<mripard>
and then U-Boot just boots the kernel with whatever DT it was given
<smaeul>
because in most cases, u-boot doesn't boot the kernel with the DT it was given
tnovotny has joined #linux-sunxi
<smaeul>
so I'd need to search the ATF->U-Boot built-in DT for whatever node I care about, and copy that to the used to boot Linux
<mripard>
well, I mean, at some point you'll have to
lkcl has quit [Ping timeout: 246 seconds]
<mripard>
that would be a solution too
lkcl has joined #linux-sunxi
<smaeul>
in terms of breaking changes, banning "fdt load" seems like a big one
<megi>
some kernel DTB fixups are done in misc_init_r in board/sunxi/board.c, for example (for SID derived stable mac/bluetooth addresses)
<megi>
that's done on the DTB loaded by u-boot from SD card
<smaeul>
megi: that looks like it's setting U-Boot environment variables, not modifying the DTB
<megi>
check setup_environment that it calls
<smaeul>
that's what I'm looking at
<megi>
it's passd the dtb blob and calls do_fixup_by_compat function
<megi>
and I can see the patched DTB from the booted kernel, so it works
<smaeul>
megi: definitely your local patch :)
<megi>
mainline patch is still pending for the merge on the mailing list
gediz0x539 has quit [Ping timeout: 268 seconds]
<mripard>
smaeul: I don't know. The requirement to using crust is having a new firmware being loaded by the bootloader before Linux, so surely a modification to the bootloader environment is pretty minor compared to it
<mripard>
but yeah, you can manipulate the DT at board level
<megi>
looks like some fixups (like fdt_fixup_ethernet, that reads those env vars set in the sunxi board code) are done by image_setup_libfdt which is called from image_setup_linux which is called from bootm
<smaeul>
mripard: okay, this seems like it _can_ work
<smaeul>
I'll have to write the code to actually ignore the protected-clocks on the Linux side
<smaeul>
(or *somebody* will; this project keeps getting bigger as time goes on)
<smaeul>
the dt-bindings headers are ABI, so I can hardcode those numbers in ATF, right?
<mripard>
smaeul: ignore won't work, but adding the CLK_IS_CRITICAL will
<smaeul>
the last thing I heard was "Yes. Use protected-clocks to indicate what shouldn't be touched by the kernel."
<smaeul>
of course his suggestion to disallow clk_get won't work, because Linux still needs to use the clock
<mripard>
smaeul: the difference is that, if you entirely ignore it, you might shut down a parent
<mripard>
because, allegedly, no one is using it anymore
<mripard>
CLK_IS_CRITICAL ensures that the clock remains on, no matter what
<smaeul>
so you don't want me to use protected-clocks? or you want me to implement it in sunxi-ng by setting the CLK_IS_CRITICAL flag?
<mripard>
the latter
<smaeul>
makes sense
<mripard>
(ideally at the framework level, but yeah)
<smaeul>
okay, so the driver doesn't actually need that patch to function... are the comments about the reset controller usage satisfactory?
selfbg has quit [Remote host closed the connection]
reinforce has quit [Quit: Leaving.]
<warpme_>
smaeul: "3:02 PM <smaeul> warpme_: the u-boot binaries for various boards are already practically the same. the only hard question is "which device tree to pass to Linux" - isn't that I can specify this in boot.scr i.e:
<smaeul>
warpme_: that means you overrode what U-Boot was doing. it still needs the right DTB though, or you may not even get far enough to run boot.scr
<warpme_>
and this is exactly my intention. I want to use u-boot just to get kernel/dtb from sd-card and let kernel + right dtb does correct init....
<warpme_>
of course dtb is exact correct for given board
victhor has joined #linux-sunxi
<smaeul>
warpme_: but u-boot may not be able to read the SD card if its DTB is wrong.
<warpme_>
idea is to have single SD image and user needs only put correct dtb (called h6_dtb) in boot part
<warpme_>
put->copy
<warpme_>
smaeul: right. that's why precondition is to have generic u-boot able to: init cpu/ram and read sd-card
tnovotny has quit [Read error: Connection reset by peer]
ldevulder_ has joined #linux-sunxi
ldevulder has quit [Ping timeout: 265 seconds]
rra has left #linux-sunxi [#linux-sunxi]
<mripard>
warpme_: RAM timings will be different from one board to another
rra has joined #linux-sunxi
<smaeul>
warpme_: you really should have the SPL as the part that changes between boards, then everything else is automatic.
aballier has joined #linux-sunxi
<smaeul>
if that's not an option, then you need to modify the function I linked above to choose a DT at runtime like mru and I suggested originally.
<smaeul>
and choose conservative RAM timings (assuming that all your boards even have the same RAM type)
<warpme_>
smaeul: sure. this is what i have now (auto-generated SD image per board). user burns card, insert and power-on. all works. what I want to achieve is to reduce number of imaged variants i need to build. Ideally will be to have universal image - but this indeed will require correct spl in board's mmc. By this i'm considering less plug-n-play model where image is single - but user requires to copy+rename right dtb
<warpme_>
from on-card repository to "h6_dtb" file. Still not full plug-n-play but for me (as distro provider) is it shorter time to build single image than multiple images
<warpme_>
yeah - RAM will be definitely issue as some of them are DDR3, some DDR3L, etc.
<smaeul>
warpme_: that's no easier than 1) write universal image to SD card 2) write correct 32k binary to SD card
<smaeul>
only a tiny binary at a known location isn't universal. the rest of your image can be built only once
<smaeul>
and then you overwrite the SPL area with the board specific binary after building (or after writing to SD card)
<warpme_>
smaeul: indeed. This seems to be good idea. I forgot about this option!. thx
rra has left #linux-sunxi [#linux-sunxi]
reinforce has joined #linux-sunxi
lkcl has quit [Ping timeout: 246 seconds]
lkcl has joined #linux-sunxi
lkcl has quit [Ping timeout: 268 seconds]
lkcl has joined #linux-sunxi
<wens>
argh, the breakage in -next isn't fixed yet
lurchi_ is now known as lurchi__
<montjoie>
I send a patch for renamin next to "sid"
yann has quit [Ping timeout: 252 seconds]
lkcl has quit [Ping timeout: 265 seconds]
lurchi__ is now known as lurchi_
hlauer has quit [Ping timeout: 250 seconds]
matthias_bgg has quit [Quit: Leaving]
florian has quit [Quit: Leaving]
Putti has joined #linux-sunxi
lurchi_ is now known as lurchi__
gediz0x539 has joined #linux-sunxi
tllim has joined #linux-sunxi
florian has joined #linux-sunxi
florian has quit [Ping timeout: 248 seconds]
<megi>
wens: what breakage?
<megi>
root mount panic stuff?
AneoX has joined #linux-sunxi
lkcl has joined #linux-sunxi
netlynx has joined #linux-sunxi
netlynx has joined #linux-sunxi
yann has joined #linux-sunxi
megi has quit [Ping timeout: 276 seconds]
gsz has quit [Quit: Konversation terminated!]
megi has joined #linux-sunxi
lurchi__ is now known as lurchi_
Putti has quit [Remote host closed the connection]