qschulz has quit [Remote host closed the connection]
qschulz has joined #u-boot
matthias_bgg has joined #u-boot
camus has joined #u-boot
vagrantc has quit [Quit: leaving]
mmu_man has quit [Ping timeout: 252 seconds]
thopiekar has quit [Ping timeout: 240 seconds]
thopiekar has joined #u-boot
Gravis has quit [Quit: Murdered]
Gravis has joined #u-boot
<sjg1>
Tartarus: sorry, spam filter, found it
<sjg1>
rfs613: Patman tries to detect the current project (see detect_project()) or you can use -p to set it
<sjg1>
rfs613: You can have different settings for each. Quite a few people use it for both Linux and U-Boot
jclsn8 has joined #u-boot
jclsn has quit [Ping timeout: 240 seconds]
sbach has quit [Read error: Connection reset by peer]
sbach has joined #u-boot
mps has quit [Ping timeout: 272 seconds]
jclsn8 is now known as jclsn
camus has quit [Ping timeout: 240 seconds]
MiNuS_89 has joined #u-boot
guillaume_g has joined #u-boot
tre has joined #u-boot
xypron has quit [Quit: xypron]
xypron has joined #u-boot
mps has joined #u-boot
mckoan|away is now known as mckoan
frieder has joined #u-boot
apritzel has joined #u-boot
monstr has joined #u-boot
tre has quit [Ping timeout: 252 seconds]
tre has joined #u-boot
apritzel has quit [Ping timeout: 240 seconds]
matthias_bgg has quit [Ping timeout: 240 seconds]
tnovotny has joined #u-boot
zibolo has joined #u-boot
matthias_bgg has joined #u-boot
camus has joined #u-boot
apritzel has joined #u-boot
MiNuS_89 has quit [Ping timeout: 252 seconds]
lucaceresoli has joined #u-boot
<milkylainen>
can u-boot create gpt tables on raw nand?
<milkylainen>
was gpt ever designed for anything beside regular blockdevices?
mmu_man has joined #u-boot
darkapex has quit [Ping timeout: 256 seconds]
prabhakarlad has joined #u-boot
darkapex has joined #u-boot
sughosh has joined #u-boot
sughosh has quit [Remote host closed the connection]
<marex>
milkylainen: the later
<marex>
milkylainen: use mtdparts of raw nand
<milkylainen>
marex: Yes. But everyone keeps telling me I shouldn't be using gpt for raw nand, but no-one gives me a real technical reason. :) I've heard some, but nothing compelling enough to tell me it's a bad idea. Well... Obviously it's a bad idea for multilevel cells without any FTL of any kind.
<milkylainen>
GPT has backup tables. SLC nand is rather resilient for something not written all the time.
<milkylainen>
mtdparts are logical. Are there any on-media partition formats?
<marex>
milkylainen: you need FTL, so you could stack up "raw nand -> ubi -> ubiblock -> gpt"
<marex>
otherwise you can place the GPT into a bad block or develop a bitflip in the GPT
<milkylainen>
So could your bootloader residing on raw nand?
<marex>
ok, so assuming you detect the bit flip (how?), you use backup table ... backup table location develops a bad block
<marex>
then when ?
<marex>
you need to relocate the backup table somewhere, how ?
<marex>
milkylainen: if your bootloader resides in raw nand, you are in a lot of problems ... it is doable and it sucks
<marex>
milkylainen: the usual approach is to have multiple copies of SPL in the first few erase blocks and that SPL should ideally support UBI and load everything from UBI (U-Boot, Linux, rootfs on ubifs)
<milkylainen>
marex: Yes it sucks. Most would go for an emmc or something with a builtin FTL.
<marex>
but that SPL itself then needs to be maintained ... so when you boot Linux, you need to have a copy of the SPL somewhere in the ubifs and every once in a while, verify that neither copy of SPL got corrupted or developed a bitflip and if it did, rewrite it
<marex>
ubi also needs maintainering , there was some daemon for that in mtd-utils
<marex>
derRichard: hello :-)
<milkylainen>
I thought ubi did scrubbing in a kernel thread?
<derRichard>
milkylainen: no, it does not
<derRichard>
it does scrubbing only if it detects bitflips
<milkylainen>
ok. So only relocation on failures?
<milkylainen>
ah
<derRichard>
but it does not scan the nand for you
<marex>
what was it, ubihealthd ?
<marex>
that was the daemon ?
<derRichard>
yes. ubihealthd is a small daemon that will randomly ask ubi to scrub a peb
<derRichard>
if you let it run over time it will sooner or later scan all the nand for you
<marex>
or you can just dd the whole ubi into /dev/null from cron if there is some known idle time
<derRichard>
the daemon itself is minimal, if you need a more advanced scrubbing plan, use ubi's ioctl interface
<derRichard>
marex: will will not cause ubi to re-read ec and vid headers
<derRichard>
nor internal volumes
<marex>
hah
<milkylainen>
do emmcs do hardware scrubbing in the background or what is the typical emmc behavior? I guess it's hidden, but emmcs don't seem overly complex from the controller perspective?
<derRichard>
milkylainen: some do. but it is all hidden
<marex>
there is a way to enforce that however
<marex>
what was that called ... hold on
<marex>
bkops ?
<derRichard>
yeah, you can trigger background operations on some devices
<derRichard>
and TBH, managed nand (emmc and such) won the war. raw nand is fading out
<milkylainen>
I fully agree. This isn't a question of technology merit but rather a theoretical one. Can an ondisk partition format like GPT live on a raw nand device, SLC or similar.
<marex>
milkylainen: not without FTL, see above
<milkylainen>
Yeah. I must be stupid or something, still don't see why. I don't really see the difference of writing an ondisk format between a SLC nand or a magnetic disk media. Eraseblocks sizes aside, it's just blocks with failure statistics?
<milkylainen>
I know it's a bad idea. :)
<milkylainen>
And yes. I know GPT typically lives on block devices, not raw nand.
<marex>
milkylainen: bitflips are the problem
<milkylainen>
mmm.
<marex>
milkylainen: they develop at random, blocks fail at random and need to be relocated
<milkylainen>
marex: You mean detected on read disturbs?
<marex>
I mean, the bitflips just happen, they just develop in the NAND over time
<marex>
derRichard: can you correct me if I'm wrong ?
<milkylainen>
Yes I know. So do all blocks of all types. Magnetic etc.
ladis has joined #u-boot
<marex>
milkylainen: not at the rate they do in NAND, not nearly so much
<milkylainen>
But that's read disturb you're talking about. Bad blocks do happen in nand, SLC types are pretty resilient though. I mean, what would be the big difference between an emmc not doing scrubbing if it relocates after the error is detected (depending on how severe the bitflip error is)?
<milkylainen>
Huh. Nintendo Switch seems like GPT on raw NAND?
<milkylainen>
Funny thing. I wouldn't recommend that. But seems like a curious choice.
<milkylainen>
marex: fwiw, thanks for bothering to explain the obvious stuff. :)
<milkylainen>
Just a curiousity thing this... "Why can't I have a ondisk partition format that survives a raw nand? Couldn't GPT?"
<derRichard>
marex: yes, bitflips develop over time
<marex>
milkylainen: leave the NAND in storage for a bit and bitflips just develop because the caps in the NAND array discharge below threshold
<milkylainen>
marex: But that's read disturb (on a previously discharged cel)? And you can't correct for any number of errors with or without ubi?
<marex>
milkylainen: read disturb is you read a cell and another cell develops a bitflip
<ladis>
milkylainen: and that's why you want to run ubihealthd even on read only volumes
<milkylainen>
ladis: Absolutely.
<milkylainen>
Also. The Nintendo Switch seems to be prone to GPT errors on that raw nand. :)
<milkylainen>
So conclusion. There is no technical aspect to stop you from using GPT on a raw nand? It's just a VERY BAD idea?
<marex>
are you sure the tegra does not have some managed nand goo in it ?
<derRichard>
milkylainen: anything on raw nand is a bad idea if you don't manage it
<marex>
why it is a bad idea to put data in raw nand, see above
<derRichard>
same applies for dtb or kernels on raw nand
<milkylainen>
I fully agree. There are very severe corruption issues with storing data on raw nand. But as I said, not merit. Technical. Can you technically use GPT on a raw nand device?
<milkylainen>
I was thinking at first that GPT can't cope with the "strange" block sizes of nand etc.
<derRichard>
you can use it on raw nand if you have a copy and a mechanism to recover
<derRichard>
just like the boot block on modern socs wenn you boot from nand. there you have also many copies...
<milkylainen>
marex: Hmm. Dunno, but looks like people are having issues with corrupt gpt. I guess if it was managed in a decent fashion there would be less corruption?
<marex>
maybe, fix it and send them a patch
<milkylainen>
:)
cyrozap-ZNC has quit [Quit: Client quit]
cyrozap has joined #u-boot
<Tartarus>
sjg1: kaki is full
MiNuS_89 has joined #u-boot
<marex>
MiNuS_89: hi, that ar93xx stuff you do, is that something on top of mainline u-boot ?
<marex>
(its good to see it even works after all this time)
<marex>
hthiery: re mx8mq clock driver, no ... I am so effing overloaded ...
<marex>
hthiery: I just hope NXP can check the tables and then we should merge it for v2022.07
<hthiery>
marex: ah ok ... I hope I can get the uart working in my case
<marex>
hthiery: btw /wrt that MALLOC_F stuff ... I ran into it with mx8mp
<marex>
hthiery: that's why it was my first suggestion
<marex>
commenting out part of the clock tables suddenly made it work
<marex>
hthiery: which UART ?
<marex>
hthiery: are you also working on that ... phone ... or some other mx8mq board ?
<marex>
the uh .... ah ... librem5 phone
<hthiery>
marex: hmmm ... my initail value was 0x2000 .. and now I have to increase it to 0x10000
<marex>
hthiery: because there is like a ton of little driver structures for each single clock which just adds up
<marex>
hthiery: it sucks, big time
<hthiery>
marex: I use the kontron-pitx-imx8m board also with an imx8mq
<marex>
hthiery: ah, you're working with frieder then ?
<marex>
hthiery: we likely need some way to flag only the clock which should be probed early on and ignore the rest , maybe with u-boot,dm-spl in DT somehow
<marex>
and dm-pre-reloc
<MiNuS_89>
marex: I sent a mail to the general mailinglist today to see if I can have few stuff to dig at to try to solve my board. And yes I do that on top of the mainline u-boot
<hthiery>
marex: in the broadest sense yes ...different locations
<marex>
hthiery: ah cool
torez has joined #u-boot
<marex>
MiNuS_89: do you have JTAG access to that board ?
<marex>
MiNuS_89: as for the spew ... could it be you have both earlycon/earlyprintk enabled and when regular console kicks in, those two both write into the UART IP ?
<MiNuS_89>
marex: yes I already failed a couple of builds trying to play around with registers ;-)
<marex>
MiNuS_89: well what happens if you disable PCIe support in the kernel, does the system finish booting ?
<marex>
maybe PCIe access screws something up
<MiNuS_89>
This kernel boot with the device original U-Boot (1.1.4)
<marex>
could be the kernel depends on some odd clock settings done by the original bootloader
<marex>
disable the PCIe support, see if it boots with new u-boot then, if so, then your problem is isolated to PCIe
<marex>
then check the clock IP and PCIe IP for any writes from the original u-boot, there might be something in start.S or arch/mips
<marex>
likely some undocumented or poorly documented register
MiNuS_89 has quit [Ping timeout: 250 seconds]
MiNuS_89 has joined #u-boot
<MiNuS_89>
marex: BTW I have access to the flash via a CH341A (direct Flash access as there is no JTAG on this board). I also have serial access on the board (a port is available)
<marex>
yikes
<marex>
pity they removed the jtag, it used to be present in those routers
<MiNuS_89>
yes until v4
<MiNuS_89>
but it's fine with a direct flash access also. You don't need to remove the chip each time. Hot flash is doable so it's fairly simple
<marex>
MiNuS_89: with jtag you can start the u-boot without even rewriting the flash, which takes a bit of time to complete
<MiNuS_89>
true
lucaceresoli_ has joined #u-boot
lucaceresoli has quit [Quit: Leaving]
lucaceresoli_ has quit [Client Quit]
lucaceresoli has joined #u-boot
tre has quit [Remote host closed the connection]
vagrantc has joined #u-boot
mmu_man has quit [Ping timeout: 240 seconds]
_whitelogger has joined #u-boot
mmu_man has joined #u-boot
tnovotny has quit [Quit: Leaving]
matthias_bgg has quit [Ping timeout: 256 seconds]
mmu_man has quit [Ping timeout: 256 seconds]
mckoan is now known as mckoan|away
frieder has quit [Remote host closed the connection]
redbrain has quit [Read error: Connection reset by peer]
redbrain has joined #u-boot
<rfs613>
sjg1: thanks for the reply regarding patman. Am currently trying it in a repo that is neither linux nor u-boot. Got it working, though I had to add a phony alias, and also --no-check as there is no checkpatch.pl in this project.
kabel has joined #u-boot
<kabel>
so I am pushing to a PR on github, but the system no longer starts CI tests on that PR. Anybody knowns the reason why?
<marex>
kabel: travis is no longer used
<marex>
I suppose that's what you are trying to trigger, right ?
<kabel>
marex: no longer used as of 2 hours ago?
<kabel>
bnecause 2 hours ago it worked. I am talking about azure builds
<marex>
Tartarus: ^
<Tartarus>
So, I guess the CI doc needs another update then
<rfs613>
marex: yeah that is how I have been doing it (before patman).
ladis has quit [Quit: Leaving]
lucaceresoli has quit [Quit: Leaving]
MiNuS_89 has quit [Ping timeout: 240 seconds]
torez has quit [Remote host closed the connection]
monstr has quit [Remote host closed the connection]
<Tartarus>
kabel: OK, so looking at the CI doc again, the other option we document is that individuals can setup their own freebie azure tier and run the pipeline. That won't be limited by what we're otherwise doing (other users, pushes to master/next/testing my own branches)
<kabel>
Tartarus: thanks, I will try to setup my own tier
MiNuS_89 has joined #u-boot
<MiNuS_89>
marex: After comparing the boot log of the same kernel with the original boot loader and the new one I found that difference. The 6 lines below are missing with the new bootloader.
<MiNuS_89>
[ 0.000000] On node 0 totalpages: 32768
<MiNuS_89>
[ 0.000000] Normal zone: 288 pages used for memmap
<MiNuS_89>
[ 0.000000] Normal zone: 0 pages reserved
<MiNuS_89>
[ 0.000000] Normal zone: 32768 pages, LIFO batch:7
<MiNuS_89>
I can't stay connected tonight but will look at the irc logs if you or someone else reply. I may miss something on memory init that generate the crash i get later.
sakman has quit [Remote host closed the connection]
sakman has joined #u-boot
<marex>
try without the PCIe enabled first
<MiNuS_89>
will generate a new kernel tomorrow
MiNuS_89 has quit [Remote host closed the connection]