Tartarus changed the topic of #u-boot to: SOURCE MOVED TO https://source.denx.de/u-boot/u-boot.git / U-Boot v2025.04, v2025.07-rc4 are OUT / Merge Window is CLOSED, next branch is OPEN / Release v2025.07 is scheduled for 07 July 2025 / Channel archives at https://libera.irclog.whitequark.org/u-boot
_whitelogger has joined #u-boot
naoki has joined #u-boot
jclsn has quit [Ping timeout: 272 seconds]
jclsn has joined #u-boot
srk has quit [Ping timeout: 268 seconds]
alperak has quit [Quit: Connection closed for inactivity]
clamor has joined #u-boot
clarity has quit [Ping timeout: 248 seconds]
clarity has joined #u-boot
teejay has quit [Ping timeout: 260 seconds]
teejay has joined #u-boot
teejay has quit [Quit: leaving]
teejay has joined #u-boot
teejay has quit [Ping timeout: 260 seconds]
naoki has quit [Ping timeout: 260 seconds]
monstr has joined #u-boot
monstr has quit [Ping timeout: 252 seconds]
mckoan|away is now known as mckoan
warpme has joined #u-boot
clamor has quit [Ping timeout: 244 seconds]
ldevulder_ has joined #u-boot
ladis has joined #u-boot
ldevulder_ is now known as ldevulder
clamor has joined #u-boot
alperak has joined #u-boot
teejay has joined #u-boot
mmu_man has joined #u-boot
sszy has joined #u-boot
clamor has quit [Read error: Connection reset by peer]
clamor has joined #u-boot
m5zs7k_ has joined #u-boot
srk has joined #u-boot
m5zs7k has quit [Ping timeout: 252 seconds]
mmu_man has quit [Ping timeout: 272 seconds]
m5zs7k_ is now known as m5zs7k
Caterpillar2 has quit [Quit: Konversation terminated!]
monstr has joined #u-boot
jclsn has quit [Quit: WeeChat 4.6.3]
mmu_man has joined #u-boot
mmu_man has quit [Ping timeout: 252 seconds]
jclsn has joined #u-boot
jclsn has quit [Quit: WeeChat 4.6.3]
jclsn has joined #u-boot
jclsn has quit [Quit: WeeChat 4.6.3]
jclsn has joined #u-boot
mmu_man has joined #u-boot
eballetbo has joined #u-boot
ladis has quit [Quit: Leaving]
mmu_man has quit [Ping timeout: 260 seconds]
tlwoerner has quit [Ping timeout: 252 seconds]
tlwoerner has joined #u-boot
ja_02 has quit [Ping timeout: 245 seconds]
mmu_man has joined #u-boot
Guest16 has joined #u-boot
rvalue has quit [Ping timeout: 272 seconds]
Guest16 has quit [Quit: Client closed]
monstr has quit [Ping timeout: 252 seconds]
rvalue has joined #u-boot
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
mckoan is now known as mckoan|away
jclsn has quit [Quit: WeeChat 4.6.3]
warpme has joined #u-boot
goliath has joined #u-boot
ldevulder_ has joined #u-boot
ldevulder has quit [Ping timeout: 252 seconds]
mmu_man has quit [Ping timeout: 276 seconds]
mmu_man has joined #u-boot
ldevulder_ has quit [Ping timeout: 260 seconds]
sszy has quit [Ping timeout: 260 seconds]
mripard has quit [Quit: WeeChat 4.6.3]
mmu_man has quit [Ping timeout: 252 seconds]
Stat_headcrabbed has joined #u-boot
Stat_headcrabbed has quit [Quit: Stat_headcrabbed]
monstr has joined #u-boot
vagrantc has joined #u-boot
ldevulder_ has joined #u-boot
mmu_man has joined #u-boot
monstr has quit [Ping timeout: 252 seconds]
derRichard has joined #u-boot
<derRichard> sjg1: i have a question on UCLASS_HOST. my plan is passing mtd devices from the host to u-boot sandbox. shall i extend UCLASS_HOST or better add a new class such as UCLASS_MTDHOST?
mmu_man has quit [Ping timeout: 252 seconds]
mmu_man has joined #u-boot
dsimic has quit [Ping timeout: 252 seconds]
dsimic has joined #u-boot
<Tartarus> derRichard: Would it be ugly / hard to extend UCLASS_HOST?
Stat_headcrabbed has joined #u-boot
Stat_headcrabbed has quit [Client Quit]
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
warpme has joined #u-boot
ldevulder_ has quit [Quit: Leaving]
<cambrian_invader> probably better to create a new uclass, since it won't be implementing a block device
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<derRichard> Tartarus: i fear it will be ugly because mtd has different semantics than block
<derRichard> but i can try and see how ugly it becomes
<Tartarus> derRichard: Well, that's a good reason to just make UCLASS_MTDHOST then
<derRichard> i'm just a bit puzzled why UCLASS_HOST is focused on block and not generic :-/
<Tartarus> Got ideas on how to make it more abstract?
<Tartarus> Likely answer is planning to work on it later if possible/needed
<derRichard> not without breaking existing commands. e.g. "host bind" assumes you create a block device. we'd need at least a type flag
<Tartarus> OK. So, yeah, thanks for talking it out. New uclass it is :)
<derRichard> having new sub commands like "host bind-mtd ..." is also not nice IMHO
<derRichard> but i'll explore and send an rfc patch :-)
ja_02 has joined #u-boot
<cambrian_invader> derRichard: maybe you can try doing an MTD IOCTL when binding to determine if you have a "real" block device or an mtd device
mmu_man has quit [Ping timeout: 260 seconds]
mmu_man has joined #u-boot
goliath has quit [Quit: SIGSEGV]
<derRichard> cambrian_invader: yes, but i plan to support mtd's with a file backend too
<cambrian_invader> how are you going to store oob data?
<derRichard> cambrian_invader: by fxing the file offsets
<derRichard> it's not the first nand simulator i wrote^^
<cambrian_invader> so inline?
<derRichard> yes
<derRichard> and for basic stuff i don't need oob at all
<derRichard> ubi does not use oob
<derRichard> oob is only needed when you want to use jffs2
<derRichard> and ecc can be a no-op
<cambrian_invader> that's how I did it with sandnand, but I think e.g. nanddump puts all the oob stuff at the end of the file
<cambrian_invader> well, some of the more interesting things to test are handling of bad blocks
<derRichard> i don't think so
<cambrian_invader> and you can't really do that without oob data
<derRichard> as i said, storing oob is not a drama
<cambrian_invader> I'm not trying to make it that way; it's just something I've been thinking about on and off
<derRichard> you can even have bad block support without oob. the fake nand driver can offer a is_bad function that queries the block state form some config file...
<derRichard> *from some
<cambrian_invader> ah, looks like nanddump does it inline too
<derRichard> yep
<cambrian_invader> maybe that was wishful thinking, since if you do the oob stuff at the end you can use shifts instead of divisions
<derRichard> at least the nand similator i wrote a few years ago could use nandump files as-is
<cambrian_invader> got a link?
<derRichard> i fear it's not free software
<cambrian_invader> alas
<derRichard> well, i'm about to redo it
<derRichard> guess why i'm exploring UCLASS_HOST :-D
<cambrian_invader> heh
<cambrian_invader> at some point I will add support for backing files to nandsim in linux
<cambrian_invader> which should be much more convenient for running tests on realistically-sized nand devices
<cambrian_invader> as opposed to stuff that must fit in RAM
<derRichard> i really need to revive my muse driver: https://lkml.rescloud.iu.edu/2101.3/00329.html
<derRichard> it allows writing mtd drivers in userspace via fuse
<derRichard> that's a simple mtd ram impelemnted in userspace: https://github.com/richardweinberger/libfuse/commit/70657d9d29c97515f7c0c99c49676ea596f25534
<cambrian_invader> I've had a good experience with vhost-user
<cambrian_invader> the nice thing about that one is that it works with the host kernel as well as emulated ones (e.g. qemu or uml)
<cambrian_invader> but there's no MTD virtio spec
<derRichard> when doing muse i had vhost-user also in mind but found it way too complicated for mtd. maybe i should give it another try
<cambrian_invader> the "modern" style is to use ring buffers (e.g. io-uring or virtio) for communication
<cambrian_invader> but AFAICT the MTD subsystem is 100% synchronous in Linux
<cambrian_invader> so I don't know if it matters
<derRichard> yes, it is
<cambrian_invader> it doesn't even handle scatter-gather :l
<derRichard> AND ubi/ubifs is using vmalloc'ed buffers :P
<derRichard> for some extra pain
<cambrian_invader> well, if you have a highmem buffer someone has to bounce it
<cambrian_invader> and MTD already does it so you might as well kick the can as far down the stack as you can
<derRichard> mtd shows it's age
<derRichard> also device model wise
clamor has quit [Ping timeout: 268 seconds]
clamor has joined #u-boot
absc has joined #u-boot
clamor has quit [Read error: Connection reset by peer]
mmu_man has quit [Ping timeout: 252 seconds]
tlwoerner_ has joined #u-boot
mmu_man has joined #u-boot
tlwoerner has quit [Remote host closed the connection]
<derRichard> hmm, the driver model integration of mtd is not really clear to me
<Tartarus> I would not be surprised if it needed a little more care and attention
<derRichard> alt least i don't see how/where mtd drivers call device_bind_driver()
f_ is now known as funderscore
warpme has joined #u-boot
absc has quit [Quit: Got to go. irctk 1.1.0-beta]
alperak has quit [Quit: Connection closed for inactivity]
warpme has quit [Ping timeout: 252 seconds]
warpme has joined #u-boot
davlefou_ has quit [Ping timeout: 245 seconds]
davlefou has quit [Ping timeout: 245 seconds]
dominic- has quit [Ping timeout: 248 seconds]
vagrantc has quit [Quit: leaving]
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]