ChanServ changed the topic of #armlinux to: ARM kernel talk [Upstream kernel, find your vendor forums for questions about their kernels] | https://libera.irclog.whitequark.org/armlinux
jlinton has quit [Ping timeout: 256 seconds]
XV8 has joined #armlinux
XV8 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
apritzel has quit [Ping timeout: 256 seconds]
shailangsa_ has quit []
shailangsa has joined #armlinux
archetech has quit [Quit: Konversation terminated!]
amitk has joined #armlinux
jn has quit [Remote host closed the connection]
jn has joined #armlinux
jn has quit [Changing host]
jn has joined #armlinux
kos_tom has quit [Ping timeout: 250 seconds]
kos_tom has joined #armlinux
elastic_dog has quit [Ping timeout: 240 seconds]
<Xogium>
so… I'm using a board with spi nand for the first time ever… And trying to understand the boot process. I see my kernel is about 4 MB, and in u-boot the kernel length is set to some 7 MB. What does linux do with the bigger length passed for booting ? Does it simply discard the possible garbage at the end of itself ?
guillaume_g has joined #armlinux
<Xogium>
I mean you have to pass the nand_kernel_length variable when booting so… I'm not sure what happens there when kernel is smaller than the length
<Xogium>
maybe I'm overthkinking this
<Xogium>
*overthinking
elastic_dog has joined #armlinux
monstr has joined #armlinux
Misotauros has quit [Ping timeout: 256 seconds]
matthias_bgg has joined #armlinux
<ukleinek>
Xogium: sounds a bit like you read 7 MB from the nand device and that's fine as long as the kernel is smaller, because the data after the kernel image is irrelevant
<ukleinek>
(that is, as long as you don't overwrite the dtb or initramfs)
apritzel has joined #armlinux
<geertu>
Xogium: it's future-proofing. Only after 3 MiB / ca. 25 KiB / kernel release, the kernel will become too big to fit.
frieder has joined #armlinux
Misotauros has joined #armlinux
djrscally has joined #armlinux
apritzel has quit [Ping timeout: 256 seconds]
<ukleinek>
The clever option would be to determine the image's size and read exactly this much. This is future proof and doesn't waste time reading unused data from NAND
<geertu>
ukleinek: agreed
<Xogium>
so wait
<Xogium>
you're saying every time I upgrade my kernel and it changes size by even one byte I have to update the u-boot env ?
<ukleinek>
Xogium: no you don't, you only need to update once the kernel image becomes > 7 MB
<Xogium>
oh
<Xogium>
so you mean u-boot should determine the kernel image size itself here, as clever option ?
<ukleinek>
Xogium: the size isn't really passed to the kernel. You only need to know the start of the image and jump into it.
Pali has joined #armlinux
<Xogium>
then… why is there a length ?
<ukleinek>
Xogium: well, the code+data has a certain size ...
<Xogium>
right
<ukleinek>
Xogium: depending on the format the kernel is in nand its more or less easy to determine the size
<Xogium>
hmmm appears to be zImage
<Xogium>
gzip
<ukleinek>
the uImage header contains it, and for zImage it's also possible
nsaenz has joined #armlinux
<Xogium>
yeah because honest, relying on nannd_kernel_length as an env variable to boot up sounds very…
<Xogium>
well how to put it
<Xogium>
not future proof
<ukleinek>
yeah, once you hit the problem because it's too low, that's ugly to debug if you forgot about it
<Xogium>
this is vendor u-boot so it doesn't surprise me they do strange things…
<Xogium>
so… what would be the correct way here ?
<ukleinek>
well, I wouldn't call it strange. That's just the easy option.
<Xogium>
they also do that for dtb heh
<ukleinek>
if you want to invest the time:
<Xogium>
honestly… investing time in this sounds like the sanest thing possible, because of all the pain it can end up causing later. Especially that I'll be adding rauc to this
<ukleinek>
A zImage starts with 8 nops (e1a00000)
<ukleinek>
then a small branch instruction (ea000005)
<Xogium>
always ? No matter the compression used ?
* ukleinek
nods
<ukleinek>
then a magic value (016f2818)
<Xogium>
so I'd have to teach u-boot about that..?
* ukleinek
nods again
nsaenz has quit [Quit: Leaving]
nsaenz has joined #armlinux
<ukleinek>
and after the magic value the start address (0 for a relocatable zImage) and then the end address
<ukleinek>
that header is defined in arch/arm/boot/compressed/head.S if you want to take a look
headless has joined #armlinux
<ukleinek>
Xogium: you'd read the first chunk from NAND, check if the magic is there and then determine the size using data[11] - data[10] (where data is an u32[])
Pali has quit [Ping timeout: 256 seconds]
<geertu>
Xogium: I guess upstream U-Boot already knows all of that, so you can lift code from that?
<Xogium>
hmm no idea
<ukleinek>
geertu: you're sure?
<Xogium>
it might, if this has been done since 2020.07
<geertu>
ukleinek: No, hence the "I guess"
<Xogium>
honest if I could use barebox I would
<Xogium>
I'm much more comfortable with that bootloader
<geertu>
Can't be this is the first platform that needs to extract the size from the image?
* ukleinek
suspects that given the trend not to use raw partitions for kernel/dtb images any more but a file system, this isn't necessary. Also given that reading from nand is done using a nand read command that need to know a specific size passed ...
<Xogium>
ukleinek: I thought u-boot only had nand read ?
<geertu>
"any more", so what did people use before? read fixed-size block, and deal with the investigation later?
<ukleinek>
Xogium: ack, that's my reasoning that a newer U-Boot probably isn't more clever here
<ukleinek>
geertu: before the images were in raw partitions and people lived with reading to much data
<Xogium>
I mean no offense but god u-boot is so… primitive
<Xogium>
wants exact address for every damn little thing
<Xogium>
or size
<Xogium>
I mean… what's so hard about using jffs2 or ubifs and just… letting you do something like load mtt 0:4
<Xogium>
maybe I'm thinking its too simple in my mind but
<javierm>
Xogium: with the EFI support in u-boot you could just load a grub EFI binary and use grub to load the kernel/initrd and boot
<javierm>
Xogium: that's what we do in Fedora
<Xogium>
heh
sszy has joined #armlinux
<Xogium>
I doubt this would work on such ancient hardware
<Xogium>
armv5
<ardb>
Xogium: EFI boot should work (i use it for testing on an old Raspberry Pi 1)
<ardb>
but building GRUB for v5 is probably going to be an issue
<Xogium>
hmm
<Xogium>
is u-boot 2020.07's EFI implemention working good ?
<Xogium>
I thought this was much more recent somehow
<Xogium>
I'd update to mainline but… yeah. This board isn't even in mainline
<Xogium>
and the SoC itself only got started, f1c200s
<Xogium>
so stuck with vendor's u-boot with a single patch on top of it
<Xogium>
so I was like, cool ! Only one patch… Until I saw the size. Almost 3900 lines
<ardb>
mine is 2020.10
<Xogium>
I suppose I could try and build grub… Buildroot might have a bunch of workarounds for armv5… In the nearly 200 patch they have on grub, that is
<Xogium>
ardb: but that would mean same issue here, since this is raw nand. I'd need to use nand read
<ardb>
ah right
<ardb>
so the benefit of GRUB is that it has a known size, right?
<ardb>
and you can load the kernel from another source?
<Xogium>
I mean if the only thing I gotta load from nand is grub and the size is extremely unlikely to change… Unlike kernel or dtb
<Xogium>
I'd assume so
<ardb>
GRUB uses the EFI block layer
<ardb>
which is exposed by uboot in this case, so if uboot cannot access it, nor can GRUB
<Xogium>
erk
<Xogium>
so much for that idea
<Xogium>
god this is giving me one nasty headache
<ukleinek>
Xogium: I suggest to live with reading to much data
<Xogium>
yeah… but it sucks
<ukleinek>
but it works
<Xogium>
the read too much data I can live with but I'll have to constantly keep in my mind the fact that there's a limit on kernel size
<ukleinek>
I think even barebox doesn't have such a support out-of-the-box. (Thought it would probably be easier to add a command for that. e.g. load_image -s /dev/nand0.kernel -t /zImage)
<Xogium>
really ?
<ukleinek>
the usual way is to have the kernel image in the rootfs for barebox, too.
<Xogium>
I'm confused… what's the point of the mtd subsystem in u-boot, let alone of it handling ubifs, if you use nand read ?
<Xogium>
maybe I'm mixing up things
alexels has joined #armlinux
<ukleinek>
a dedicated ubifs for just one file isn't very beneficial
<Xogium>
nah but I thought of storing dtb and kernel inside /boot in rootfs or something
<ukleinek>
Xogium: yeah, with zImage and dtb in the rootfs, you don't use nand read and so don't need to guess the size to load.
<Xogium>
kind of struggling to understand these raw partitions and weather they are even useful
<Xogium>
I'd rather have just 2 ubifs for rootfs 1 and 2
<Xogium>
I suppose I must pass mtdpart= on kernel command line to do this though, to override the default hardcoded in the device tree ?
<Xogium>
128
<Xogium>
oops
<Xogium>
I mean 128 MB nand
<Xogium>
could have been worse
<Xogium>
to me it seems like raw partitions are a bad idea because they would have no wear leveling performed or anything
matthias_bgg has quit [Ping timeout: 256 seconds]
tre has joined #armlinux
<milkylainen>
Xogium: Depends on the media?
matthias_bgg has joined #armlinux
apritzel has joined #armlinux
ravan has quit [Remote host closed the connection]
ravan has joined #armlinux
ravan has quit [Changing host]
ravan has joined #armlinux
headless_ has joined #armlinux
headless has quit [Read error: Connection reset by peer]
headless_ is now known as headless
Misotauros has quit [Ping timeout: 245 seconds]
ravan has quit [Ping timeout: 272 seconds]
jtf has quit [Ping timeout: 256 seconds]
jtf has joined #armlinux
nq has joined #armlinux
iivanov_ has quit [Quit: Leaving...]
iivanov has joined #armlinux
headless has quit [Quit: Konversation terminated!]
<mort>
What was the interface you were supposed to use for GPIO now that the sysfs approach isn't recommended?
<mort>
right, with the <linux/gpio/driver.h> I suppose
<mort>
do you happen to know around when the chardev interface was introduced?
iivanov__ has joined #armlinux
iivanov has quit [Read error: Connection reset by peer]
<arnd>
mort: linux-4.6
<mort>
ah. I need to stick with the sysfs interface then
<mort>
at least for the time being
<arnd>
the oldest kernel that is still getting updates it v4.9 now, so you should be fine relying on it
<mort>
nope
<mort>
this is embedded, the bsp from the vendor is a patched 4.4
<arnd>
mort: if the hardware is old enough to run 4.4 and the soc has not seen anyone sending mainline support in the past 6 years, then you should consider it dead
<mort>
I appreciate your input but it's not gonna change anything
<mort>
it's things like this which makes me feel like the entire kernel community is completely out of touch with the entire embedded community tbh
<arnd>
mort: most of the embedded community is on board, if you use a SoC from Freescale, TI, Microchip, ST, or Qualcomm, you will find them supported on mainline kernels just fine
<mort>
being supported by the mainline kernel isn't enough though
<broonie>
There's a huge chunk of the embedded community is much more engaged with mainline - the microcontrollerish people for example tend to have minimal out of tree code, and the people targetting Android are pulled along by the need to support current Android versions (even if they're just going for AOSP not Google's releases).
<mort>
there's more to a SBC than the CPU
<broonie>
The third party chip vendors have the same constraints.
<mort>
plus, all the major SOC vendors tell you to use their kernel fork
<mort>
even if it's technically supported by mainline, all documentation for almost all SOC vendors tells you to use their fork
<broonie>
Will their support people meaningfully give you the time of day though? Part of the reason the microcontrollerish people support mainline well is that their customer base is getting more support from the community than the vendor since they tend to have many small customers.
<mort>
having documentation to follow is useful.
<arnd>
mort: it is a problem that some of them consider the problem "done" when the hardware is shipped. If you ask them for support, they can only help you if use you version they used during bringup because their development team has moved on to the next chip after they got it out.
<mort>
arnd: I don't see how that changes anything
<mort>
in fact, it kinda... supports my point?
<arnd>
mort: it means that if you need support, you need to go elsewhere, either a manufacturer that cares about their products long-term, or a consultant that works with mainline
<arnd>
there is very little value in being able to ask questions about a 7 year old OS without bugfixes and security updates
<mort>
the official way to use almost all SOCs is to use the vendor's kernel fork. What you're saying doesn't change that.
<broonie>
And only on their reference boards! :P
<mort>
no, not really -- but usually, out-of-tree drivers are provided for the kernel fork's version, not for mainline
<mort>
you're trying to paint this rosy picture where everyone is on mainline and there are no out of tree drivers for any hardware but that's... not reality
<mort>
as I said, there's more to an SBC than the CPU
<broonie>
Most vendors that are actively doing anything useful aren't shipping anything that far back, there's constraints pulling them forwards.
<mort>
even the DTS for their reference boards (which are useful to base your own DTS on) won't be compatible with mainline
<mort>
because Linux keeps breaking dts compatibility
<broonie>
They're more targeting the actively maintained LTSs - usually with a heavy emphasis on more current ones.
<geertu>
mort: Do you dare to connect a system running the vendor's v4.4 to the Internet?
<mort>
I've never seen an SOC vendor which keeps their kernel fork up to date with the latest LTS
<broonie>
The microcontroller people are the main ones there - the Androidish people tend to just stop supporting their older chips usefully (some handwave in between of course).
<mort>
never heard of renesas-rcar
<geertu>
(ok, they're not at v5.15 LTS yet)
<mort>
it doesn't seem like a soc vendor?
<mort>
anyways, enough about this, I'll just use the sysfs interface and get on with my life
<geertu>
mort: What do you mean, no SoC vendor?
<mort>
the company which makes the SoC
<mort>
sorry if I'm using incorrect terminology
<geertu>
mort: Never heard of Renesas?
<mort>
no
<milkylainen>
Renesas is a _large_ player.
<milkylainen>
Remnants of Hitachi.
<mort>
seems very car-focused
<geertu>
Merger of Hitachi, NEC and Mitsubishi microelectronics
<geertu>
arnd: yep, these are more recent acquisitions. All related to support ICs, not the actual SoCs.
<geertu>
mort: Which SoCs are you using?
<arnd>
geertu: right, the last IDT processors are long gone
<milkylainen>
I have a really peculiar problem on a 5.4.181 LTS. The initramfs cpio refuses to start. Unpacks alright, no errors. Freeing unused initramfs. But nothing. Not getting a "starting xyz as init process" either. Kernel just completes all initialization then sits quietly.
<geertu>
arnd: bye bye mips
<milkylainen>
Can't figure out what I've missed. devnodes look ok. executable looks fine...
<geertu>
milkylainen: And 5.4.1.180 is fine?
<milkylainen>
geertu: Probably not the kernel. I'm convinced I must have mucked something up. But can't for the life of me figure out what.
<arnd>
geertu: I was thinking of the Centaur x86 ones that ended up at VIA/Zhaoxin, I guess they still had MIPS chips after that
<mort>
geertu: one from rockchip
<mort>
it's supported in mainline, but I know how much work it is to upgrade a kernel and try to forward port some out-of-tree drivers and find in-free replacements for others so that's a big project for later
<milkylainen>
arnd: Didn't Intel buy Centaur from VIA?
<arnd>
milkylainen: Intel got the engineers and patents, Zhaoxin got the technology
<mort>
plus userspace interfaces tend to change quite drastically between kernel versions IME, especially stuff like how video encoder/decoder drivers behave
<milkylainen>
arnd: Ah.
Amit_T has joined #armlinux
Misotauros has joined #armlinux
ravan has joined #armlinux
sudeepholla has quit [Read error: Connection timed out]
sudeepholla has joined #armlinux
amitk_ has joined #armlinux
amitk has quit [Ping timeout: 240 seconds]
ziofork5 has joined #armlinux
jlinton has joined #armlinux
tre has quit [Remote host closed the connection]
suzukikp has joined #armlinux
prabhakarlad has quit [Quit: Client closed]
russ has quit [Ping timeout: 240 seconds]
frieder has quit [Remote host closed the connection]