<Daulity>
I notice it takes a while for my kernel to start
<Daulity>
is that time that it's extracting linux into ram?
<zmatt>
I mean, what are you measuring exactly?
<Daulity>
not measuring but just wondering
<zmatt>
yes but what is "taking a while" ? the time between what and what?
<Daulity>
the time between u-boot and the start of the kernel is like a good maybe 6 - 10 seconds
<zmatt>
how do you define "start of the krenel" ?
<zmatt>
*kernel
<Daulity>
start is first message in console
<Daulity>
like this: [ 0.000000] Booting Linux on physical CPU 0x0
<Daulity>
maybe i shouldn't have said starting linux because u-boot says that at the end before it jumps to the kernel
<zmatt>
it'll take a while before the serial console is in working state, at which point log messages accumulated in the kernel log ringbuffer will be dumped to the serial console
<zmatt>
though 6-10 seconds sounds excessive
<zmatt>
dunno, hard to make a guess based on this limited info...
<Daulity>
yea about 8 seconds (with a timer on my phone) is the time between when u-boot says "staring kernel ..." and the first console message.
<Daulity>
it's not impeding the function of the device but it's something i noticed and maybe it's normal
LetoThe2nd has joined #beagle
<zmatt>
it doesn't sound normal to me
<zmatt>
I've had beaglebones fully booted in 10 seconds
<Daulity>
I just hooked up a beagle bone black that i had laying around and when starting it the time between "starting kernel ..." and the first console message is way shorter like 2 seconds timed on my phone :)
<zmatt>
so is this a custom-built kernel or something?
<zmatt>
I can imagine an 8-second delay if some driver required to get the serial console working has been built as module instead of being compiled into the kernel
<Daulity>
yea it is a custom build kernel
<zmatt>
the kernel log itself should reveal that though
<zmatt>
note that in that case there's no actual delay in starting the kernel, just in seeing console output
<Daulity>
here is dmesg output: https://termbin.com/l8u9 i do not see anything like serial delay or waiting for serial in there
<zmatt>
[ 4.614330] console [ttyO0] enabled
<zmatt>
so that doesn't explain the entire delay, but at least some of it
<zmatt>
my own kernel: [ 0.335776] console [ttyS0] enabled
<Daulity>
do i need early printk for that?
<zmatt>
a significant amount of time seems to be taken on your machine by boot-time benchmarking of software RAID6 implementations... you may want to disable that assuming you have no actual need for software RAID :P
<zmatt>
no
<zmatt>
afaik not
<zmatt>
it _might_ depend on CONFIG_SERIAL_EARLYCON not sure
<zmatt>
but I don't think so
<zmatt>
afaik that timestamp is showing when the proper/normal serial console is setup
<zmatt>
it looks like earlycon is only used when explicitly enabled at runtime using the earlycon kernel parameter
<Daulity>
on my config SERIAL_EARLYCON=y
<zmatt>
yeah I don't think it's relevant
<Daulity>
but indeed don't need that RAID
<zmatt>
and it seems you're using omap-serial rather than 8250-omap, dunno whether that makes any difference here
<Daulity>
i see only one option when i earch for raid that is enabled: RAID6_PQ [=y]
<zmatt>
btw I recommend adding rng_core.default_quality=100 to your kernel parameters to get the kernel to actually *use* the hwrng
<Daulity>
good idea thanks for the tip :)
<zmatt>
on my own kernel I have CONFIG_RAID_ATTRS=n which seems to remove all other RAID config options
<zmatt>
it seems the default beaglebone kernel has CONFIG_RAID6_PQ=y but CONFIG_RAID6_PQ_BENCHMARK=b
<zmatt>
=n
<zmatt>
also your kernel is built for SMP, might want to disable that since you're not targeting a multi-core cpu
<zmatt>
(CONFIG_SMP=n)
<zmatt>
Daulity: also I see systemd complaining about some stuff, there are some notes I made a while ago regarding kernel config it prefers: https://pastebin.com/G0JQxgj6
<zmatt>
*these are
<zmatt>
actually CONFIG_DMIID is not needed, pretty sure that's x86-specific
<zmatt>
or at least not applicable to the beaglebone
<zmatt>
(it seems it is supported on some ARM systems)
<Daulity>
on my config CONFIG_RAID_ATTRS disabled too
<zmatt>
huh, I assumed that was the reason I had no other RAID options, I guess I'm wrong
<Daulity>
this option CONFIG_RAID6_PQ_BENCHMARK doesn't seem to exist
<zmatt>
might be an rcn patch
<Daulity>
atleast a search in menuconfig doesn't find that
alan_o has quit [Ping timeout: 272 seconds]
<zmatt>
doesn't matter since you don't need RAID (presumably) so you can just disable it entirely
<Daulity>
oh alright might be then this kernel is from the TI sdk
<zmatt>
ah, I have CONFIG_MD=n
<zmatt>
that explains the lack of raid config options
<Daulity>
zmatt: where is the complaint in the dmesg you see?
<zmatt>
[ 7.796372] systemd[1]: system-getty.slice: unit configures an IP firewall, but the local system does not support BPF/cgroup firewalling.
alan_o has joined #beagle
<Daulity>
good catch i'll have to add it to my list :)
<zmatt>
yeah it's not required of course, but it's a useful bit of security hardening
<Daulity>
i disabled CONFIG_DM but it's still doing the raid benchmark i think the raid option is selected by serveral other options.
<zmatt>
CONFIG_MD, CONFIG_DM is something else
<Daulity>
I meant MD
<zmatt>
well then hunt down the causes and slay them ;)
<Daulity>
BTRFS_FS needed to be disabled too in my case
<Daulity>
now it's disabled
<zmatt>
oh that's possible, I have that disabled anyway
<zmatt>
probably
<zmatt>
I don't actually, CONFIG_BTRFS_FS=m
<Daulity>
yep just tested and it's gone from dmesg :)
Shadyman has quit [Quit: Leaving.]
<Daulity>
yep it's about 4.3 seconds now
<Daulity>
think i'll try 8250-omap too
<Daulity>
see what that does
<Daulity>
oops i think i disabled the wrong thing there is no serial output from the kernel :P
<Daulity>
but i can access it throug the network so it booted :D
<zmatt>
oh nice, fastly just broke... or at least their servers in amsterdam... and with it a ton of websites
<zmatt>
check you have CONFIG_SERIAL_8250_OMAP_TTYO_FIXUP=y
<Daulity>
fastly?
<zmatt>
content delivery network
<zmatt>
ah the problem is already on wikipedia "On 8th June 2021 Fastly reported problems with their CDN service which resulted in many of the world's busiest websites being unavailable such as Reddit, the UK Government, and The Guardian."
<Daulity>
i got serial output again but did not do much for the time :)
<zmatt>
25 minutes of downtime for sites like twitch and reddit... I imagine some people at fastly are sweating pretty badly right now :D
ogra has quit [Ping timeout: 265 seconds]
ogra has joined #beagle
<zmatt>
oooouch, affected sites included "Reddit, Spotify, Twitch, Stack Overflow, GitHub, gov.uk, Hulu, HBO Max, Quora, PayPal, Vimeo, Shopify, Stripe, and news outlets CNN, The Guardian, The New York Times, BBC and Financial Times"
Shadyman has joined #beagle
starblue has joined #beagle
<jkridner>
NishanthMenon: do you know if it is true that any GPIO can be used as a card detect for the microSD?
<zmatt>
so yeah the precedence is: 1. check non-removable flag 2. check gpio 3. check if card detection declared as "broken" 4. check sdhci card detect (i.e. using peripheral card detect pin)
<NishanthMenon>
jkridner, "ROM relies on SDCD pin for detection"
<jkridner>
thanks
<jkridner>
:-(
<zmatt>
ROM cares about the CD pin?
<zmatt>
why would it do that instead of just attempting communication
<NishanthMenon>
zmatt, supposedly from our rom guys.. kishon additionally added another concern: "like for instance the IP waits for 2ms to detect card.. say if we use gpio and we try to access card how the IP will respond is something has to be checked"
<zmatt>
I don't follow
<zmatt>
the point is card detect is being able to know when a card is being hot-inserted while the system is running... booting from a card requires it to be present at reset, and ROM has nothing to gain from using card detect
<NishanthMenon>
zmatt, i think kishon's concern is what happens in arasan state machine when CD is NC.
<zmatt>
ROM shouldn't even configure the CD pin in the first place, it should configure the sd controller to ignore CD
<NishanthMenon>
zmatt, i agree on what ROM should probably do.. trying to confirm from ROM team if they are indeed using CD signal as entry to boot criteria..
Shadyman has quit [Quit: Leaving.]
<zmatt>
if it does, that should probably get a bug report for future mask revisions
<zmatt>
I just checked, the am335x does not use a card detect pin in mmc/sd boot modes
<zmatt>
am335x rom
<NishanthMenon>
zmatt, correct, and I believe we have used gpio for CD in the past extensively
<zmatt>
yes, card detect can use a gpio, hence you usually do use a gpio since then you can use whatever pin is left over
<zmatt>
arasan = am654x ?
<NishanthMenon>
arasan hardware is the mmc controller. it is used in all k3 devices - am654, j721e/tda4 etc..
<zmatt>
ah
<zmatt>
but I don't get what this issue relates to
<NishanthMenon>
zmatt, the arasan hardware's internal statemachine is tied to the CD signal, as far as I understood briefly.
<zmatt>
so it's not sdhci-compliant?
<NishanthMenon>
zmatt, ummm... that, I am not sure..
<zmatt>
like, it's true that card detect prevents setting power-on... *unless card detect is disabled*
<zmatt>
by settings bits 6-7 of the Host Control 1 register
<zmatt>
*setting
<zmatt>
which is no doubt what linux does when you use a gpio for cd
<zmatt>
I assume? not sure how else it would work
<zmatt>
trying to dig through it
<zmatt>
interesting, linux has an arasan-specific quirk for it: SDHCI_ARASAN_QUIRK_FORCE_CDTEST
<zmatt>
I don't really understand why it's used only there, like I don't understand how gpio card detect is supposed to work without it in general
<zmatt>
I guess it's not needed if the card detect signal is asserted when it's not muxed to any pin.. dunno if that's the case
<NishanthMenon>
vigneshr, ^^ any clues?
<zmatt>
sometimes there are other implementation-specific ways of making the sdhci controller ignore card detect, but bits 6 (CDTL) and 7 (CDSS) of host control are the portable way, so I kinda assumed that's what's always used when card detect is to be ignored
<zmatt>
like, how does it work for eMMC? there is no card detect signal whatsoever in that case
<NishanthMenon>
Aswath, you might be the right guy to help explain the mmc thingy.. see chat log for history
<zmatt>
yeah, the beaglebone dts configures the card detect pin to gpio mode, not to the mmc-cd mux mode (which *is* available on that pin)
<Aswath>
zmatt I think there is no issue with implementing card detect using gpio in linux after adding support to populate gpios. The only issue right now is that the ROM is using the native card detect signal and it will not be possible to boot out of SD
<zmatt>
why on earth does ROM use a card detect signal at all instead of just attempting communication? which is what ROM does on every previous TI SoC afaik
<zmatt>
e.g. am335x, am572x
<zmatt>
(maybe not keystones? I'm unfamiliar with those)
<zmatt>
Aswath: especially since the boot device might be eMMC/eSD in which case no card detect signal exists in the first place
<Aswath>
zmatt Need a few minutes to get info on ROM side of things
GooberMan has joined #beagle
<zmatt>
ah looks like keystone 1/2 didn't support mmc/sd boot at all (just digging around a bit to see what behaviour other TI SoCs specify)
<zmatt>
the netra/centaurus/subarctic/aegis happy family (dm816x/dm814x/am335x/am437x) all use only 6 pins: clk+cmd+dat0-3 (no card detect pin)
<zmatt>
omap4: "The ROM code does not handle the card detection feature on the card cage."
<zmatt>
looks like the new keystone 3 devices are the first to make the curious decision to mux and use the card detect pin
<zmatt>
(assuming it actually does)
jkridner[m] has quit [Read error: Connection reset by peer]
mvaittin has quit [Read error: Connection reset by peer]
shoragan[m] has quit [Write error: Connection reset by peer]
shoragan[m] has joined #beagle
mvaittin has joined #beagle
jkridner[m] has joined #beagle
set_ has quit [Ping timeout: 252 seconds]
<Aswath>
zmatt ROM waits on SDCD line for booting from SD. This essentially adds a feature to hotplug SD card while booting
<zmatt>
I think they usually just rely on the fact that the card detect signal is seen as low by the peripheral when not muxed to any pin, and the omap-hsmmc peripheral treats that as asserted by default
<zmatt>
Aswath: I mean, every previous SoC would just cycle through the boot device(s) until able to boot
<zmatt>
so you kinda get that "feature" for free anyway
<zmatt>
so all this does is prevent people from reusing that pin for a different purpose
<zmatt>
(and put card detect, if the device is removable in the first place, on a random gpio)
<Aswath>
zmatt Yes this true. I'll try to get more information from ROM team and understand other reasons for why SDCD line was used
<zmatt>
I think ignoring refraining from muxing the pin (and, if necessary, setting bits 6-7 of the HOST_CONTROL1 register) would be an improvement
<zmatt>
*ignoring card detect by refraining from muxing the pin
Aswath has quit [Quit: Client closed]
Guest90 has joined #beagle
ds2 has quit [*.net *.split]
ds2 has joined #beagle
LetoThe2nd has quit [Quit: Connection closed for inactivity]
Guest12 has joined #beagle
Guest12 has quit [Client Quit]
M-blaise has quit [Ping timeout: 272 seconds]
m-atoms has joined #beagle
Guest90 has quit [Ping timeout: 250 seconds]
Posterdati has quit [Read error: Connection reset by peer]
argonautx has joined #beagle
aswin has joined #beagle
<aswin>
While cross compiling the kernel I am getting an error
<aswin>
./include/linux/kconfig.h:7:10: fatal error: generated/autoconf.h: No such file or directory
<aswin>
I was trying to build kernel 5.10 for BBB. By default SELinux feature is ON
<aswin>
When I disabled SELinux using menuconfig. Kernel starts compiling without any issue.
<aswin>
So I am missing some dependancies
<aswin>
How to pass linux headers when I am cross compiling ?
Posterdati has joined #beagle
_Posterdati_ has joined #beagle
Posterdati has quit [Client Quit]
_Posterdati_ has quit [Client Quit]
Posterdati has joined #beagle
_Posterdati_ has joined #beagle
Posterdati has quit [Client Quit]
_Posterdati_ has quit [Read error: Connection reset by peer]
Posterdati has joined #beagle
<zmatt>
aswin: the easiest way to build a custom kernel is to use rcn's build scripts, see these notes: https://pastebin.com/eLhrp1Hg
<zmatt>
of course if you just want a 5.10 kernel then you can just install one with apt instead of compiling one from scratch
<zmatt>
that error doesn't sound like a missing dependency, more like a makefile or build script broke
<aswin>
zmatt: I was trying do it in the hard way to learn.
<zmatt>
first google result seems to imply that error happens when there's no kernel config
<zmatt>
which you then created using menuconfig
<aswin>
I was using the bb.org_defconfig
<aswin>
then kernel build failed
<aswin>
I went and desabled SELinux from the menuconfig
<aswin>
then build succeeded
<zmatt>
why did you disable selinux?
<zmatt>
why would you even think that has anything to do with it?
<zmatt>
that's saying it's missing an auto-generated config header, which is being included by linux/kconfig.h which is included (directly or indirectly) in every source code
<zmatt>
presumably this was simply the first thing that failed