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
<hanetzer>
y'think it may be that the u-boot is so shite that I'ma have to pass mem=x like the vendor kernel?
<hanetzer>
nah. that didn't do it. but, it looks like I'm just 'idling'
<marex>
hanetzer: if the U-Boot port is actually for another board with different amount of DRAM, you might need this mem= workaround ... with vendor downstream forks, nothing would surprise me
<marex>
wait, one thing would ... if they pointed me to find sources in upstream, period
<hanetzer>
marex: nah. their idea of memcfg is a blob of 4096 bytes which acts as a sort of binary csv file :P
<hanetzer>
so, just copypasta that into a fresh build, same memcfg.
<hanetzer>
yes. its terrible.
<hanetzer>
the blob is produced from an excel file with vba macros.
<marex>
seems similar to what NXP does with iMX8M DRAM calibrator
<marex>
excel file generates a page which you have to copy-paste into text file, feed that text file to windoze tool which really behaves the same way as u-boot mkimage + uuu (pastes blobs together at the right offsets and loads them via USB), but then (!) the tool communicates with the blobs via UART, using plain text and binary protocol combination , and then the tool captures some output via UART and spits .h
<marex>
C header file ...
<marex>
if you are wondering why this insane complexity and why the tool at all if the logic is likely just a bit of bit frobbing ... no idea
<marex>
but it is truly insane too
<marex>
hanetzer: you did try embedding the initramfs into the kernel, right ?
<marex>
hanetzer: that is. point the kernel config to the initramfs root directory and let the kernel figure the rest out ?
<hanetzer>
marex: ah, not like that. I just handed it the cpio produced by buildroot
<marex>
hanetzer: might be worth a try, if only to eliminate the possibility that the CPIO archive is somehow corrupted before it is passed to Linux
<hanetzer>
yeh. seems like no joy there tho
<marex>
hanetzer: how did you start that kernel ?
<marex>
what was the u-boot command ?
<hanetzer>
bootm $addr
<hanetzer>
preceded by a tftp $addr $kernelfile
<marex>
so I assume you have built-in initramfs and DT both, right ?
<marex>
and this is uImage then ?
<marex>
or fitImage ?
<hanetzer>
uImage(zImage(cpio)+dtb)
<hanetzer>
because that's the best I can manage on the vendor-boot
<marex>
so the kernel image with the initramfs in it is like 10 MiB now, right ?
<hanetzer>
6.2m
<marex>
looks OK
<hanetzer>
(remember, I killed the hwdb files outta it)
<marex>
hanetzer: are you still passing the initrd to the kernel by any chance ?
<hanetzer>
no, not in the last boot.
<marex>
(just to eliminate that possibility)
<marex>
ok
<hanetzer>
initrd doesn't live on the flash, I have to deliberatelyl tftp it over.
<marex>
hanetzer: did you try the keep_bootcon like j`ey suggested ?
<hanetzer>
yeah, didn't make a whiff.
<marex>
hanetzer: well, make menuconfig -> Kernel hacking -> printk and dmesg options -> increase log level to maximum and see if you can spot anything
<marex>
also, I assume you do have SERIAL_AMBA_PL011_CONSOLE=y
<hanetzer>
yee
apritzel_ has quit [Ping timeout: 256 seconds]
<hanetzer>
fuck my life.
<hanetzer>
nixed out the arm,armv7-timer node in dts and blamo.
<hanetzer>
fuck. my. life.
<hanetzer>
well, for what its worth it still fubar's the reading of the sqshfs rootfs.
<hanetzer>
oh wait. didn't enable mtd_blk
tiagom has joined #armlinux
tiagom has quit [Quit: leaving]
tiagom has joined #armlinux
<marex>
hanetzer: so the timer was the problem ?
<hanetzer>
yeh, but I think the squash is still borked. testing now.
<marex>
hanetzer: at least now you can experiment with mtdblockX access in Linux
<marex>
from initrd
<hanetzer>
yeh.
<hanetzer>
ok, can't be certain, but it seems that every differing byte from the *real* squashfs on my hdd is 0x08, 0x80, or 0x88 'too low'
<hanetzer>
so I guess that means it "can't read" either of these bits 0b10001000
tiagom has quit [Ping timeout: 272 seconds]
<hanetzer>
I may have figured out the last issue as well... my dumb ass was reading the mux regs for the standard primecell spi controllers, not the specialized hisilicon spi nor/nand controllers
<hanetzer>
nope. drat.
<hanetzer>
fug it. I can login now. I can work on other drivers and shiz while I wait on action on the lkml
<hanetzer>
hopefully I can manage to get the sata or usb working. makes things a bit easier :)
mvaittin has quit [*.net *.split]
sicelo has quit [*.net *.split]
georgem has quit [*.net *.split]
krzk has quit [*.net *.split]
krzk has joined #armlinux
georgem has joined #armlinux
sicelo has joined #armlinux
sicelo has quit [Changing host]
sicelo has joined #armlinux
mvaittin has joined #armlinux
ndesaulniers has quit [*.net *.split]
sven has quit [*.net *.split]
xdarklight has quit [*.net *.split]
matthiasbgg[m] has quit [*.net *.split]
Patater has quit [*.net *.split]
javierm has quit [*.net *.split]
_jannau__ has quit [*.net *.split]
Sledge has quit [*.net *.split]
hauke has quit [*.net *.split]
javierm has joined #armlinux
_jannau_ has joined #armlinux
Sledge has joined #armlinux
ndesaulniers has joined #armlinux
hauke has joined #armlinux
sven has joined #armlinux
Patater has joined #armlinux
xdarklight has joined #armlinux
matthiasbgg[m] has joined #armlinux
guillaume_g has joined #armlinux
prabhakarlad has joined #armlinux
monstr has joined #armlinux
<Xogium>
huh, but don't you generally need an timer node in dt ?
tre has joined #armlinux
frieder has joined #armlinux
mcoquelin has quit [Remote host closed the connection]
Pali has joined #armlinux
mcoquelin has joined #armlinux
headless has joined #armlinux
<hanetzer>
well, I *have* four arm,sp804 timers available
<hanetzer>
and each of those have two timers each
<hanetzer>
so, now to figure out the net situation. the ethernet block in the datasheet very closely matches the hisi-gmac driver. but if I enable it I get 'inconsistent rx_skb' until the system straight up crashes :P
sszy has joined #armlinux
Turingtoast has joined #armlinux
<hanetzer>
drivers/net/ethernet/hisilicon/hix5hd2_gmac.c file in question
<hanetzer>
rebooting is still busted tho
djrscally has joined #armlinux
ziofork52 has quit [Read error: Connection reset by peer]
ziofork52 has joined #armlinux
apritzel_ has joined #armlinux
<hanetzer>
however, now it doesn't return to bootrom, it just halts :)
apritzel_ has quit [Ping timeout: 248 seconds]
guillaume_g has quit [Quit: Konversation terminated!]
headless has quit [Quit: Konversation terminated!]
guillaume_g has joined #armlinux
<hanetzer>
ah, crash fixed(?) but I still can't ping out over it :)
Turingtoast has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
torez has joined #armlinux
<marex>
Xogium: I recall seeing something similar with mx7d with timer on smp, but that certainly wouldn't be my first pick, not even second, to look for initramfs issues
<Xogium>
what I thought too
<hanetzer>
yeah.
<hanetzer>
maybe I needa see about those 'not-fw-configured' dt flags eh.
Turingtoast has joined #armlinux
apritzel_ has joined #armlinux
headless has joined #armlinux
Turingtoast has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
Amit_T has joined #armlinux
<hanetzer>
wooo, network is up
<Xogium>
yay !
<hanetzer>
yee. now I gotta get some form of persistent storage going
<Xogium>
might want to go ubifs
<Xogium>
its better than mtdblock with squashfs
<Xogium>
if your flash is big enough, that is
<hanetzer>
well, I'ma email the hisi-sfc people about it, because if I can't read bits 0b10001000 there's not much point :)
<hanetzer>
32MiB
<hanetzer>
I'ma try to get sata/usb up.
<Xogium>
hmm
<hanetzer>
lotta storage there.
<Xogium>
ah yeah if that's available, even better
<hanetzer>
however I do want spi running at some point :)
<Xogium>
hmm, I don't know if 32 MiB us good for ubifs
<Xogium>
er, is good
<hanetzer>
had a device with 128MiB of nand but I borked it somehow
<hanetzer>
like seriously borked.
<hanetzer>
$300, poof.
<Xogium>
oww
<Xogium>
psu ?
<hanetzer>
i'ma get another one tho.
<hanetzer>
prolly. 48v/2.5a
<Xogium>
I did use something with 128 MiB for a while but… I found it way, way, way too slow to boot, it wasn't even dual spi or quad-spi it was plain spi
<Xogium>
loading a 2 MB kernel from it took a good 6 or 7 seconds
<hanetzer>
this is qspi I think
<Xogium>
I suppose would be about the speed of some mmc then
<Xogium>
at any rate, better than spi ;p
<Xogium>
all in all getting to a login prompt took 50 seconds or so, in part because of the time kernel took to fixup ubifs at the first boot, but also because the uart took about 15 seconds just to initialize itself