<Tartarus>
Author: Marek Vasut <marek.vasut+renesas@mailbox.org>
<Tartarus>
Date: Sat Oct 7 23:41:04 2023 +0200
<Tartarus>
test: bdinfo: Test bdinfo -h
<Tartarus>
breaks sandbox_flattree
<Tartarus>
(hash is wrong, I had to make a rebase tree to run a bisect)
<Tartarus>
Or more clearly, doesn't work on sandbox_flattree, nor do the next 2 other tests
qqq has joined #u-boot
<marex>
Tartarus: oh, I know what it is
Clamor has quit [Ping timeout: 264 seconds]
Clamor has joined #u-boot
<Tartarus>
Ah, thanks, doing a quick CI run and then pushing
stefanro has quit [Quit: Leaving.]
goliath has joined #u-boot
<marex>
jaganteki: would be good to discuss the HDMI stuff here instead of PM
<marex>
jaganteki: esp. if that's U-Boot question and I have no experience with rockchip HDMI , so maybe someone can help here
<jaganteki>
marex: thanks
bradfa has quit [Read error: Connection reset by peer]
bradfa has joined #u-boot
<jaganteki>
I believe the question is real and generic. do we have any existing solution that possible to register a clock and use in another u-class driver like phy
<jaganteki>
this generally useful in clock-output-names
<jaganteki>
here, the phy driver need to register the hdmi_phy clock and resue the ops with in the driver as refoclk 24MHz is parent.
<jaganteki>
It is possible to register clk uclass driver in phy driver via bind. the question that possible to use it as it is clock-output not a real clock that can get it from clock-names
davlefou has quit [Ping timeout: 256 seconds]
Stat_headcrabed has joined #u-boot
* marex
unpacks rk3588 orangepi 5 plus and just ... cries
<marex>
archaic software, blobs, all the wrongness, sigh
<Clamor>
jaganteki: if you have a dm clock driver it should handle clocks well.
<Clamor>
marex: ptsd :(
<Forty-Bot>
neat, someone using getopt :)
<marex>
Forty-Bot: I live in the future :)
<jaganteki>
clamor: point is phy driver to register output clock and reuse it. rk3328. This output clock is not clock driver assignee
<Clamor>
Refoclk?
<Forty-Bot>
that reminds me that I should probably look at whether we can use getopt instead of open-coding it everywhere
<Forty-Bot>
it's possibly a size reduction, but only if a lot of commands get converted
<Forty-Bot>
jaganteki: maybe create a second driver and bind it to the same ofnode
<Forty-Bot>
anyway, as a general comment clock-output-names is not useful in U-Boot
<Forty-Bot>
since U-Boot does not require all clocks to have a globally-unique name
<jaganteki>
problem comes when we compute the output clock configuration. here the hdmi_phy must have a clock set, round rates that compute the negotible HDMI TDMS clock based on the parent rates.
<jaganteki>
s/TDMS/TMDS
davlefou has joined #u-boot
camus has quit [Ping timeout: 260 seconds]
<Forty-Bot>
jaganteki: ok, so pass the phy driver data to the clock
<Forty-Bot>
*phy private data
<Forty-Bot>
the easiest way is probably to pass the phy dev to the clock as driver data
<Forty-Bot>
and then just access the phy dev's private data
sarg has joined #u-boot
<marex>
Forty-Bot: ew ? Looks like separation violation, no driver should access other drivers' private data like that
<Forty-Bot>
they are the same device
<Forty-Bot>
and probably live in the same file
<Forty-Bot>
in Linux this would be one driver
<Forty-Bot>
so I don't really see a problem
<Forty-Bot>
the main purpose of not accessing other driver's private data is that it makes it difficult to modify the driver's private data without introducing bugs
<Forty-Bot>
but that is not an issue here
<marex>
oh ok
<marex>
seems like rk3588 somehow needs tee, but there is no mention of tee in the docs, joy
<marex>
oh ok, seems like I got it somehow booting, SPL is still ancient, but U-Boot seems to be up to date now
<marex>
so ... ethernet, broken ... OK, that rules out network boot, but let's try USB
<marex>
OK ... usb reset ... hangs, that rules out USB
<marex>
ok ... ethernet does not work, USB still hangs ...
<marex>
Kwiboo: ^
slobodan has joined #u-boot
<marex>
oh 'pci enum' , that is where the ethernet is
mirko has joined #u-boot
<mirko>
i figured in order to read (raw) from an (e)MMC partition, i could do: `mmc dev 0 $PART ; mmc read $LOADADDR 0 128` - however followed `md $LOADADDR` does not show me the expected results (but only NULLs)
<mirko>
how can I read N blocks from the very beginning os a specific DOS/MBR partition?
<marex>
mirko: mmc dev 0 1 ; mmc read $loadaddr 0 0x10 ... will read 16x512 Bytes from eMMC BOOT HW partition 1 (the first one, A) to $loadaddr
<marex>
the var names are case sensitive, it is $loadaddr , not $LOADADDR
<Tartarus>
mirko: Er, you're confusing HW partitions and SW partitions?
<mirko>
based on v2023.10
<mirko>
Tartarus: elaborate please?
<Tartarus>
So if you want to read:
<Tartarus>
2 22528 30720 40643955-02 83
<marex>
mirko: eMMC has support for hardware partitioning , and within those hardware partitions, you can have software partitions
<Tartarus>
That's SW partition #2, and so 0:2
<Tartarus>
not HW partition number 2
<Tartarus>
ie in Linux, /dev/mmcblk0p2 is 0:2 in U-Boot (more or less)
<Tartarus>
but /dev/mmcblk0boot0 is `mmc dev 0 1` (confusing? Yes, eMMC is confusing and I'm only pretty sure I'm right about that being 1 and not 0 0, heh)
<mirko>
so `mmc dev 0 0:2` is what i'm supposed to do?
<Tartarus>
no, mmc dev 0
<Tartarus>
mmc read $loaddaddr 0:2 ...
<Tartarus>
er
<mirko>
`mmc read 11000000 0:2 8` in my case?
<Tartarus>
no
<Tartarus>
Sec..
<marex>
mirko: what are you trying to do, read content of a software partition ?
<Tartarus>
Why are you trying to read the filesystem itself in to memory?
<mirko>
marex: no filesystem on that partition but a uImage
<Tartarus>
I'm not immediately sure we outright support that outside of sandbox
<mirko>
when i talk about partition i mean MBD/DOS partition
<Tartarus>
mirko: Then you want to use the fs loading commands
<Tartarus>
not the raw read an mmc device commands
<marex>
mirko: is there a filesystem on that partition ?
<Tartarus>
ie load mmc 0:2 $loadaddr /boot/uImage
<mirko>
marex: "< mirko> marex: no filesystem on that partition but a uImage"
<marex>
mirko: can you make one and place the image into it ?
sarg has quit [Ping timeout: 256 seconds]
<mirko>
there's no filesystem - the uImage id dumped directly into/onto the partition
<marex>
mirko: that will make things easier, since the fs provides size info of that file
<mirko>
marex: technically, yes, but it's not really an option in this case
<Tartarus>
mirko: Ok, so, uh
<Tartarus>
you want to do something like
<mirko>
i'm wondering, why is raw-reading from a partition so hard?
<Tartarus>
mmc dev 0
<marex>
mirko: because nobody implemented it or nobody cares enough to make it easier, send patch ?
<Tartarus>
mmc read $loadaddr ...block number that your Image starts at, starting from zero of the eMMC user area... number-of-blocks
<Tartarus>
That's how you would handle this odd case
<mirko>
marex: i wasn't complaining, i just wonder that it's not a thing. would have figured it's quite common.
<marex>
mirko: people mostly use filesystem instead of raw files, simply because the filesystem gives them the file metadata (size mostly)
<Tartarus>
If you can change this setup, do so
<Tartarus>
otherwise you can do it via mmc read
<mirko>
Tartarus: that's how i know i can do it (and did, see above pastebin) - i just figured i'd be more flexible in terms of partitzion size changes if i'd address the partition instead of an sbolute addr in flash
<marex>
Forty-Bot: ^ you once mentioned there was some generic specifier for partitions
<Tartarus>
You just need to calculate the starting block number
<Tartarus>
based on sectors/sizes
<Tartarus>
mirko: Oh
<Tartarus>
Yeah, the flexible option is to use a filesystem :)
<Tartarus>
lets see
<mirko>
can i extract the partition starting points somehow within the shell?
<Tartarus>
Yeah, if you want to be smarter about sizes, use "part" to get some of that informaiton
<mirko>
i mean, technically, `mmc part` provides this info already
<Tartarus>
" - set environment variable to the start of the partition (in blocks)\n"
<marex>
Tartarus: more like part list
<Tartarus>
marex: Yeah, but I think mirko wants to script things?
<marex>
Tartarus: doesn't part list give you that listing and store it into env var too ?
<mirko>
ah, i didn#t see `part` - only `mmc part`
<marex>
but part start/part size looks like it, you're right
<Tartarus>
marex: Ah, yeah, the help message for that should be cleaned up a bit
<marex>
Tartarus: true
<mirko>
awesome, thanks!
gsz has quit [Ping timeout: 264 seconds]
<mirko>
that was extremely helpful, `part` does the job - thank again Tartarus and marex !
<Tartarus>
Welcome
mmu_man has quit [Ping timeout: 268 seconds]
thopiekar has quit [Ping timeout: 256 seconds]
mmu_man has joined #u-boot
thopiekar has joined #u-boot
<mirko>
just playing around with `part` and "part type <interface> <dev>:<part> <varname>" does not seem to work according help
vagrantc has joined #u-boot
<mirko>
expectation would be that `part type mmc 0:2 var` works - but it only prints the help text
vagrantc has quit [Client Quit]
<Clamor>
marex: is software subpartitioning supported by u-boot?
<marex>
mirko: is CONFIG_PARTITION_TYPE_GUID enabled in your config ?
<marex>
Clamor: I think for mbr it is
<marex>
for gpt I dunno
<Clamor>
Interesting. Thanks
GNUtoo has quit [Remote host closed the connection]
GNUtoo has joined #u-boot
thopiekar has quit [Ping timeout: 260 seconds]
<sjg1>
Tartarus: Disabling the fs_helper pylint error seems OK to me. I suppose we could put the helps in a different directory, but let's worry about it if it comes up again
<mirko>
marex: no, but why would i need it for an mbr/dos partition?
<marex>
mirko: see end of cmd/part.c
<mirko>
i see the ifdef, still confused, but will give it a try - thanks