luke-jr has quit [Read error: Connection reset by peer]
jernej has joined #linux-sunxi
luke-jr has joined #linux-sunxi
jernej has quit [Client Quit]
jernej has joined #linux-sunxi
jelly-home is now known as jelly
jernej has quit [Client Quit]
jernej has joined #linux-sunxi
jernej has quit [Client Quit]
jernej has joined #linux-sunxi
jernej has quit [Client Quit]
jernej has joined #linux-sunxi
jernej has quit [Client Quit]
jernej has joined #linux-sunxi
jernej has quit [Remote host closed the connection]
jernej has joined #linux-sunxi
jernej has quit [Client Quit]
jernej has joined #linux-sunxi
<Ashleee>
is this the equivalent of the rx-delay and tx-delay 500ps that I had to add to SOPINE dtb?
<Ashleee>
also how can you fit a kernel let alone anything more into the 16MB SPI flash? :D even barest of the barest kernels has got 18MB and I stripped everything non-GPU related, only kept bare ethernet (as I use the kernel on A64/H6/rk3399)
<hramrach>
but with A64/H6/rk3399 you support 3 platforms, 2 of them significantly different
<Ashleee>
yeah, but everything but AXP200 (or whatever is on H6) is module
<hramrach>
also there is the advanced Kconfig option for disabling core features ;-)
<Ashleee>
:)
<Ashleee>
I mean I have burned only u-boot to SPI NOR flash and the rest is either netbooted or on the sd card because I am too lazy but still :D
<karlp>
try harder? openwrt gets kernel and more into easily 16meg with room to spare :)
<Ashleee>
yeah :)
<Ashleee>
but I am a lazy person :D
<hramrach>
u-boot takes < 1MB which leaves 15MB for kernel
<hramrach>
pretty doable if you build only for the specific device and use case
<Ashleee>
I mean my ideal system would contain only glibc + busybox + one app (as it requires glibc, cannot be statically linked)
<Ashleee>
if I could fit that alongside kernel into the 16 megs I would be golden
<Ashleee>
permanent storage would be sd card anyways
<Ashleee>
for /var/lib
<Ashleee>
but I am too rough at reading CLFS :)
<hramrach>
if you use the SD card anyway it's easier to just write the kernel there
<Ashleee>
I've had sometimes the SD card not detected in u-boot on normal Pine64 every few reboots if I boot off SD, for whatever reason
<Ashleee>
no such problem with u-boot in SPI
<hramrach>
but the need to strip down everything for embedded devices is exactly the reason distributions like openwrt or yocto exist
<Ashleee>
:)
<Ashleee>
btw, anybody here has SoPine clusterboard? I have the known problem with reboots, but no solutions worked so far
<Ashleee>
from what I've heard it works fine with normal baseboard so it must be some routing issue
<Ashleee>
my one idea was to trigger watchdog for reboot
<hramrach>
watchdog is used for reboot by sunxi-fel - should work pretty realiably, and you can tune the parameters to work reasonably fast as well
<Ashleee>
if I can get it working in upstream kernel with (whatever, say systemd which *should* support it)
<mps>
cat: /sys/devices/virtual/thermal/thermal_zone0/temp: Operation timed out
<Ashleee>
hmm I remember having some issues with i2c on H6 with 5.8 kernels but I am too lazy to retry as I have to pull out the board for serial port :)
<hramrach>
yse but we don't know if that's the virtual sensor in the sysfs
<hramrach>
bucause we don't know what driver or compatible that one has
<mps>
looks like lamobo R1 is unmaintained
<mps>
I'm surprised that it works at all
<asdf28>
:->
<hramrach>
it does not need more changes when it works ;-)
<mps>
even badly :)
<hramrach>
mps: I suggest you decompile the DT from the running kernel and compare it with some known good source. The driver should be the same on either board and the difference between the DTs in kernel tree is minimal between the two boards
<hramrach>
but if the bootloader gives you something old you can get issues
<mps>
hramrach: why decompile, can I look at source, dts
<hramrach>
but you don't know if what you got came from that source or some other source
<mps>
this kernel is built from clean 5.8.14 mainline
<hramrach>
and you are sure you are loding the DT that came with teh kernel?
<mps>
yes
<hramrach>
then I don't see any reason why the thermal sensor would work on one board and fail on another
<mps>
I wouldn't reboot now to assure but I did looked lot times that u-boot loads proper dtb
<hramrach>
unless you already added the workaround disabling the senosor to some startup script ;-)
<hramrach>
you don't need to reboot. You can install dtc, and compare the dts you get from your dtb with the dts ou get from the running kernel
<mps>
hmm, I'm building and maintain all these for alpine linux (sorry for being shameless)
<hramrach>
then you probably know what you are doing
<mps>
but ok, I can decompile and compare
<hramrach>
anyway, it's good to have a way to check, I have done that on my devices when things did not work as expected to make sure that I don't hae a stale DT somewhere
<mps>
well, I don't 'fine points' of that board, had a hope someone here can help me
<mps>
maybe someone already had this problem and (hopefully) fixed it
<mps>
hramrach: anyway, thank you for hints and patience
<hramrach>
determining the revision of the SoC on each board might be also a useful datapoint. IIRC there were some revisions of the silicone
<mps>
this started to happens after 5.7 (or it was 5.6) kernel upgrade, with 5.4 and earlier I never seen this
thefloweringash has joined #linux-sunxi
MartijnBraam has joined #linux-sunxi
solderfumes[m] has joined #linux-sunxi
JuniorJPDJ has joined #linux-sunxi
fevv8[m] has joined #linux-sunxi
Irenes[m] has joined #linux-sunxi
davidebeatrici has joined #linux-sunxi
mahoux has joined #linux-sunxi
Ke has joined #linux-sunxi
return0e[m] has joined #linux-sunxi
insep_ has joined #linux-sunxi
z3ntu has joined #linux-sunxi
psydruid has joined #linux-sunxi
clementp[m] has joined #linux-sunxi
TiD91 has joined #linux-sunxi
Jeremy_Rand_DT[4 has joined #linux-sunxi
hpagseddy[m] has joined #linux-sunxi
z3ntu_ has joined #linux-sunxi
<mps>
and the board is one of the first on the market, iirc
<Ashleee>
thanks, I just noticed I was missing the axp20x adc driver :)
camus1 has joined #linux-sunxi
kaspter has quit [Ping timeout: 260 seconds]
camus1 is now known as kaspter
<hramrach>
mps: looks like the of_thermal driver that consumes that data was added since 5.4
<hramrach>
so with 5.4 the sensor might hav ebeen equally broken but with nothing reading from it you would not notice
<hramrach>
or maybe it was just renamed
<mps>
probably it is added with this termal control cooling in latest kernels
<hramrach>
hm, the only notable change seems 34471abfc8fe ("thermal: of-thermal: add API for getting sensor ID from DT")
<hramrach>
other than the driver rename
<mps>
I'm lost cable to access my disk (usb ssd) where I keep kernel git tree so can't see
<mps>
hope that new cable will arrive tomorrow
luke-jr has quit [Read error: Connection reset by peer]
luke-jr has joined #linux-sunxi
bauen1 has joined #linux-sunxi
maz has quit [Remote host closed the connection]
maz has joined #linux-sunxi
bauen1 has quit [Ping timeout: 258 seconds]
cmeerw has quit [Ping timeout: 246 seconds]
yann has quit [Ping timeout: 240 seconds]
reinforce has quit [Quit: Leaving.]
cmeerw has joined #linux-sunxi
cmeerw has quit [Ping timeout: 240 seconds]
<charco>
I'm working with the SNES Mini, and after compiling fes1.bin and executing it, DRAM seems to be available, but u-boot has problems reading from flash memory.
* charco
Well, I noticed that when I compile fes1.bin with an older gcc version (gcc-5 instead of gcc-9), it works. So I am trying to understand what could be wrong with the newer gcc version.
<charco>
Well, I noticed that when I compile fes1.bin with an older gcc version (gcc-5 instead of gcc-9), it works. So I am trying to understand what could be wrong with the newer gcc version.
<charco>
(sorry)
<charco>
According to this: https://linux-sunxi.org/FES it seems like fes1.bin might enable the FES mode (not only FEL).
<hramrach>
there might be something wrong with the code rather than the gcc
lukedashjr has joined #linux-sunxi
<charco>
That's what I am thinking. I am trying to figure out what could be wrong
<hramrach>
and finding it might be difficult unless you know what to look for.
<charco>
From reading the wiki it now seems that just running fes1.bin doesn't enable FES mode, you are still in the FEL mode, and you do need to run uboot to get into FES mode.
<charco>
yeah, I was wondering what was more or less the main responsibilities of fes1.bin other than enabling DRAM.
luke-jr has quit [Ping timeout: 264 seconds]
<charco>
Is it in charge of also enabling NAND access?
<hramrach>
how big is the fes1.bin?
<charco>
iirc the gcc-9 version was smaller than the gcc-5 version, but I would have to check (I don't have my computer with me right now)
<charco>
DO you think that the size could be too big?
<hramrach>
you can try to disassemble the objects making up fes1.bin compiled with either gcc looking for suspicious differentces but if it is big it will be hard to find
lukedashjr is now known as luke-jr
<hramrach>
and without knowing which function it is that is failing
<charco>
That is exactly what I did yesterday. nm to lookup each symbol, objdump --disassembly=func and looked at each of the functions.
<charco>
most of them were the same except different offsets
<charco>
a few were completely changed, but I have no idea what to do from there.
<charco>
I was thinking maybe there were some builtin test commands to test fes1.bin, or making sure that the state of the system after executing fes1.bin was as expected.
<hramrach>
you could try replacing the different functions one by one to find which one breaks it.
<charco>
That would be kind of hacky as I would need to compile each function into a different object file
<hramrach>
not really, you can compile .c files into .s files, swap the assembly as needed, and then link the final file
luke-jr has quit [Read error: Connection reset by peer]
gaston1980 has joined #linux-sunxi
luke-jr has joined #linux-sunxi
Mangy_Dog has quit [Ping timeout: 260 seconds]
<MoeIcenowy>
jernej: interesting, lemme check\
kaspter has quit [Remote host closed the connection]