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
<marex>
rfs613: compatible = "vendor,chip", "spidev"; doesn't work ?
milkylainen_ has quit [Quit: Ping timeout (120 seconds)]
<marex>
rfs613: u-boot has sspi command, it can talk to any SPI device, with or without a driver, it just send a transmission via SPI ... no userspace, no nothing, it is just an u-boot command
<marex>
just pick a bus, chipselect, send/receive ...
<marex>
rfs613: also, have a look at 'udevadm info /dev/device' , that will tell you the HW path and driver associated with the device , there is zero need for driver-specific compatible strings (=wrong) in the DT
djrscally has quit [Ping timeout: 268 seconds]
nsaenz has quit [Remote host closed the connection]
<Xogium>
so… If I have a mcu that lets you map part of its internal or external flash as additional ram, how can I make use of this in linux ? Is there any driver or code that can handle this ? Say I want to take 16 MB off the external qspi flash and use them as ram so I have 32 mb instead of 16 available…
<Xogium>
I know I can do this with a rtos, but I wonder if linux can help you do this
<Xogium>
heh and before ukleinek gets me I mistyped 32 MB
<Xogium>
:D
<Xogium>
now… I could be mixing stuff up heh I'm still learning mcu and all of that :)
<ukleinek>
Xogium: I guess just setting it up in the bootloader and add an appropriate memory node in dts should do the trick.
<ukleinek>
(for 32 mb this isn't worth the effort though :-)
<Xogium>
ukleinek: yeah… as long as you don't write in there too often, it could be good…
<Xogium>
I mean, I can't even have zram
<Xogium>
I'd have used this instead
tudorel has joined #armlinux
<Xogium>
zram requires zsmalloc, whatever that exacly is and this requires full MMU. Sorry guys, only have MPU
apritzel_ has joined #armlinux
<milkylainen>
Xogium: Masochistic tendencies? :) I mean. A modern kernel on an MCU with only 16M RAM and then a userspace of sorts? I guess it's possible, but it sounds like a lot of pain.
<milkylainen>
I'm guessing some kind of custom Linux, right?
apritzel_ has quit [Ping timeout: 264 seconds]
<Xogium>
milkylainen: yeah, definitely custom. Well, made using buildroot
<Xogium>
and I've done it mostly as a proof of concept :p show that it was doable, for the most part. I'm just very curious
tudorel has quit [Read error: Connection reset by peer]
tudorel has joined #armlinux
tudorel has quit [Read error: Connection reset by peer]
tudorel has joined #armlinux
<milkylainen>
Xogium: Ok. Is it a vanilla kernel that buildroot is using?
<Xogium>
milkylainen: yeah, I made all of this on my own actually, there's no config for f769 in br. But yes it is vanilla and didn't require any patching
<Xogium>
5.15.3 kernel
<milkylainen>
So vanilla with some sort of tinyconfig?
<milkylainen>
I haven't built minimalist stuff in ages. :)
<Xogium>
vanilla with stm32_defconfig with a few tweaks, mainly the dram address start / size
<Xogium>
kernel's 1.5 MB compressed in gzip
<Xogium>
I do wonder if I could make it even smaller
tudorel has quit [Quit: tudorel]
<Xogium>
[ 45.413884] nommu: Allocation of length 724992 from process 65 (getty) failed
<Xogium>
oops
Pali has joined #armlinux
<milkylainen>
busybox getty?
shawnguo has joined #armlinux
<Xogium>
hehe nah kernel
<Xogium>
I tried and stuffed a complete busybox in
<Xogium>
it did not like that
apritzel_ has joined #armlinux
bps has joined #armlinux
bps has joined #armlinux
bps has quit [Changing host]
<jn>
hm? where can i find that implementation of getty?
<Xogium>
jn: hah I blinked and was like… What ? And then realized I used the wrong word
<Xogium>
I meant to say busybox not kernel
<Xogium>
XD
<jn>
ah, so that's a yes to milkylainen
<Xogium>
no he said barebox
<Xogium>
unless I'm going deaf…
<Xogium>
oh wait I am
<Xogium>
:p
<Xogium>
for real I mean
<jn>
happens to the best of us :)
<Xogium>
yeah
bps has quit [Ping timeout: 264 seconds]
bps has joined #armlinux
bps has joined #armlinux
bps has quit [Changing host]
prabhakarlad has joined #armlinux
apritzel_ has quit [Ping timeout: 268 seconds]
<milkylainen>
busybox getty? under busybox?
<Xogium>
milkylainen: sure ? Busybox has a getty
<milkylainen>
This is confusing. Yes. That is what I'm saying.
bps has quit [Ping timeout: 250 seconds]
<milkylainen>
"hm? where can i find that implementation of getty?"
<milkylainen>
"busybox getty? under busybox?"
<Xogium>
oh no that was because I said kernel getty
<Xogium>
lol
ardb has joined #armlinux
bps has joined #armlinux
bps has joined #armlinux
bps has quit [Changing host]
ardb has quit [Ping timeout: 268 seconds]
<jn>
confusion all around
<milkylainen>
indeed.
<Xogium>
land of confusion
<Xogium>
there a way to get rid of this ? XIP start address may cause MPU programming issues
<Xogium>
aside from disabling the MPU that is
apritzel_ has joined #armlinux
<jn>
Xogium: as far as i can see, the linker script that prints this warning expects the start address to be aligned to 1 MiB
<jn>
ASSERT(!(_xiprom & (SZ_1M - 1)), "XIP start address may cause MPU programming issues")
<jn>
ASSERT(!(_exiprom & (SZ_128K - 1)), "XIP end address may cause MPU programming issues")
<jn>
so the first step would be to find out where this start address is in your build
<Xogium>
jn: hmm this would explain… I am trying to figure out if I need u-boot for this or not…
<Xogium>
like could I just burn xipImage on the flash at the correct address
<jn>
the warning is already produced by a linux linker script, so it should probably be fixed in linux configuration
<Xogium>
no bootloader involved at all, except the ROM ?
<Xogium>
I'm trying to get rid of the use for a micro sd card ;)
<Xogium>
so I have internal and external flash but I don't know how to XIP to external flash not to mention linux dt probably doesn't have this
<jn>
XIP usually requires that the code/data memory (flash) is directly memory-mapped by hardware, and there's no step of loading all that stuff into RAM before execution
<jn>
RAM might still be used for writable data
<Xogium>
jn: ah, yeah… makes sense. I *think* the stm32f769 has this
<Xogium>
memory map for the internal and external flash, that is
<Xogium>
I was planning on trying to stuff the whole thing as cramfs
<Xogium>
not kernel but at least userspace
<Xogium>
I'm sort of following the serie Nocolas Pitre wrote about shrinking the kernel to the best of my ability
<Xogium>
erm, Nicolas Pitre that is
<Xogium>
so I guess… Like, can I get rid of u-boot and directly boot kernel ?
<Xogium>
or should I stick to u-boot in spl mode
<Xogium>
with falcon mode
<jn>
not necessarily
<jn>
there might be some necessary hardware initialization that uboot does
<jn>
SPL + kernel might be enough
<Xogium>
hmm
<Xogium>
well, u-boot spl is 30 kb so that's ok
headless has joined #armlinux
<Xogium>
30 KB for spl, 1.7 MB for kernel so far
<Xogium>
might get rid of the entire block layer since I don't use usb or don't plan to keep using micro sd
bps has quit [Ping timeout: 240 seconds]
<Xogium>
so all I need to do you say, if I can arbitrarily address the external qspi flash via memory map, is just get some range of it to use as XIP ? Hmm
<Xogium>
but what about u-boot, doesn't it need to init said qspi flash ?
<Xogium>
like with sf probe or some such
<Xogium>
hmm… I treid to put the kernel in the same place that u-boot.bin was previously at in the map… SPL now hangs after trying to boot from XIP