matthewcroughan has quit [Ping timeout: 245 seconds]
zibolo has quit [Ping timeout: 268 seconds]
zibolo_ has joined #u-boot
camus has quit [Ping timeout: 268 seconds]
camus has joined #u-boot
tambarus has quit [Quit: Connection closed for inactivity]
camus1 has joined #u-boot
camus has quit [Ping timeout: 268 seconds]
camus1 is now known as camus
davlefou_ has quit [Ping timeout: 246 seconds]
davlefou_ has joined #u-boot
runtux has quit [Ping timeout: 260 seconds]
camus1 has joined #u-boot
camus has quit [Ping timeout: 268 seconds]
camus1 is now known as camus
runtux has joined #u-boot
camus1 has joined #u-boot
camus has quit [Ping timeout: 260 seconds]
camus1 is now known as camus
tambarus has joined #u-boot
ts_ has joined #u-boot
<ts_>
lists_driver_lookup_name return NULL,how to fix it?
matthias_bgg has joined #u-boot
camus1 has joined #u-boot
camus has quit [Ping timeout: 268 seconds]
camus1 is now known as camus
tnovotny has joined #u-boot
camus1 has joined #u-boot
camus has quit [Ping timeout: 268 seconds]
camus1 is now known as camus
tre has joined #u-boot
Xavier7 has joined #u-boot
mmu_man has joined #u-boot
ts_ has quit [Quit: Leaving]
Xavier7 has quit [Quit: IRcap 8.72 ]
Xavier7 has joined #u-boot
camus1 has joined #u-boot
camus has quit [Ping timeout: 268 seconds]
camus1 is now known as camus
<mwalle>
sjg1: i was just discussing with hthiery about binman. problem is, that its very tightly coupled with u-boot but (usually) needs external files which aren't part of u-boot.
<mwalle>
sjg1: this makes image building really hard IMHO
<mwalle>
sjg1: would it be possible, that you can replace binman blobs later on?
mckoan|away is now known as mckoan
<mwalle>
sjg1: ie. if you build u-boot binman will integrate all blobs which are part of u-boot (spl, u-boot proper, maybe fdts)
<mwalle>
sjg1: but then you can use binman *externally* to actually add any missing blobs, like optee, bl31 and so on
<mwalle>
sjg1: then a buildsystem like buildroot can easily build all the needed blobs and later on integrate em into the final image
<mwalle>
sjg1: it will also have the advantage, that you (or a user) can replace any blobs in an image. I.e. you can take an image and just update optee, by replacing the optee blob in place
sszy has joined #u-boot
<mwalle>
sjg1: disadvantage will be that you have to remember some metadata and store it in the image, or if there isn't any metadata, you cannot replace the blobs anymore
camus1 has joined #u-boot
camus has quit [Ping timeout: 268 seconds]
camus1 is now known as camus
Xavier7 has quit [Quit: IRcap 8.72 ]
Xavier7 has joined #u-boot
Xavier7 has quit [Client Quit]
Xavier7 has joined #u-boot
smartin has joined #u-boot
Xavier7 has quit [Quit: IRcap 8.72 ]
Xavier7 has joined #u-boot
camus1 has joined #u-boot
camus has quit [Read error: Connection reset by peer]
<vfazio>
it's OK to ping patch delegates? i don't want to be a PITA, but would like to know if there's something i can do for the series i submitted since we've had a couple of people hit the email list asking about MMC on the rpi being slow
Xavier7 has quit [Quit: IRcap 8.72 ]
tnovotny_ has joined #u-boot
tnovotny has quit [Read error: Connection reset by peer]
<sjg1>
mwalle: It is not intended to be tightly coupled with U-Boot. We use it with Zephyr in Chrome OS, for example
ilunev has joined #u-boot
<sjg1>
mwalle: See the 'fdtmap' which is a complete image description, enable to extract and regenerate the image
<sjg1>
mwalle: See also the 'replace' command which allows you to replace images, with the entries resizing as needed (so far as the test coverage covers)
<sjg1>
mwalle: It could perhaps be included in u-boot-tools
<sjg1>
mwalle: and actually I have always envisaged it working in two stages (one within U-Boot or whatever project is using it, one 'final' step without)
<sjg1>
mwalle: However it does work much better if projects to produce individual binaries instead of built images
Gravis has joined #u-boot
Gravis has quit [Ping timeout: 256 seconds]
wyre has joined #u-boot
<mwalle>
sjg1: with tightly coupled i also mean that u-boot itself makes use of the binman features like to binman symbols and so on
<mwalle>
sjg1: ok, didn't know that! so bascially its all there already. nice
<sjg1>
mwalle: Yes but do note that symbols (I assume you mean for SPL) can be added in the final step. My expectation is that the image produced by the U-Boot build is ignored, if there is a 'final-stage' build. The final-stage build can just use the individual binaries and do everything that is needed
<sjg1>
mwalle: Re all being there, that is the idea, but we will see
<mwalle>
sjg1: but if you consider my buildroot case, instead of copying all the files into the bootloader directory (which is quite hackish). you could build u-boot, optee and tf-a as seperate entities. then in the final step you'll combine all of them. thats just one part of the image. another is the rootfs/kernel for example
Gravis has quit [Ping timeout: 260 seconds]
monstr has quit [Remote host closed the connection]
<sjg1>
mwalle: Yes that's right, binman should do that easily enough. It can pull things from different directories. When I say 'image' I mean the firmware image. Binman is not designed for rootfs/kernel due to its in-memory approach, although I suppose that is a matter of memory usage
<sjg1>
mwalle: Think of binman as the tool that combines all the binaries, adds a few extra, dynamic things and stitches everything together, e.g. by adding metadata and updating parts of the binaries too
<sjg1>
mwalle: This includes signatures, firmware ID strings, U-Boot environment and the like
Gravis has joined #u-boot
matthias_bgg has quit [Read error: Connection reset by peer]
<apalos>
sjg1: that's were I actually lost the point, the mmio interface for the tpm is an ioread
<apalos>
so i cant see what is there to abstract, but maybe I am missing something
<sjg1>
apalos: What is an ioread? You mean I2C or SPI?
mckoan is now known as mckoan|away
lucaceresoli has joined #u-boot
tnovotny has quit [Quit: Leaving]
Gravis has joined #u-boot
<apalos>
sjg1: read from a memory mapped interface,
<apalos>
maybe it's clearer now with the spi interface,
<apalos>
but basically what the tpm2_tis_core function does, is abstract thge standard TPM API
<apalos>
and the only this you have to register, is how to access your devices, e.g read/write bytes
<apalos>
what could make some sense, although I am not 100% sure, is move those function into the DM itself,
urja has quit [Ping timeout: 260 seconds]
matthias_bgg2 has quit [Ping timeout: 268 seconds]
urja has joined #u-boot
mmu_man has quit [Read error: Connection reset by peer]
mmu_man has joined #u-boot
torez has joined #u-boot
redbrain has quit [Quit: leaving]
behanw has joined #u-boot
redbrain has joined #u-boot
torez has quit [Ping timeout: 268 seconds]
smartin has quit [Remote host closed the connection]
smartin has joined #u-boot
___nick___ has quit [Ping timeout: 268 seconds]
torez has joined #u-boot
torez has quit [Ping timeout: 264 seconds]
lucaceresoli has quit [Ping timeout: 256 seconds]
mripard has quit [Ping timeout: 268 seconds]
torez has joined #u-boot
vagrantc has joined #u-boot
mripard has joined #u-boot
redbrain has quit [Ping timeout: 268 seconds]
<robher>
sjg1: for pylibfdt, are you tied to distutils over setuptools for any reason? For pypi, it needs a 'wheel' which needs setuptools.
torez has quit [Quit: torez]
smartin has quit [Quit: smartin]
tambarus has quit [Quit: Connection closed for inactivity]
jsmolic has quit [Ping timeout: 264 seconds]
<sjg1>
apalos: If it is read/write MMIO then it could use regmap, if you don't want a uclass. I agree that a uclass for MMIO has never quite hit the threshold of desirability. There has been talk of a class that can handle register access over either I2C or SPI, bus I think this is something different from what you need, right?
<sjg1>
robher: Not that I know of. So long as it is compatible / works, which it should do