hulu1522 has quit [Read error: Connection reset by peer]
hulu1522 has joined #linux-sunxi
reev has joined #linux-sunxi
IgorPec has joined #linux-sunxi
p1u3sch1 has quit [Ping timeout: 264 seconds]
p1u3sch1_ has joined #linux-sunxi
IgorPec has quit [Ping timeout: 276 seconds]
kz1 has joined #linux-sunxi
<lennyraposo>
tux logo is out the window
<lennyraposo>
;)
avph has quit [Ping timeout: 246 seconds]
avph has joined #linux-sunxi
<lennyraposo>
gonna have a debian build with DE ready for this week ;)
KotCzarny has joined #linux-sunxi
kz1 has quit [Ping timeout: 240 seconds]
kz1_ has joined #linux-sunxi
IgorPec has joined #linux-sunxi
IgorPec has quit [Ping timeout: 276 seconds]
robogoat has joined #linux-sunxi
robogoat_ has quit [Quit: Reconnecting]
reev has quit [Ping timeout: 252 seconds]
IgorPec has joined #linux-sunxi
cnxsoft has quit [Read error: Connection reset by peer]
cnxsoft has joined #linux-sunxi
<montjoie>
yeah EMAC still working after a nigth:)
Incursion has joined #linux-sunxi
<wens>
mine works pretty well actually
<wens>
though the early RX/TX interrupt message pops up
<wens>
and I get TX FIFO full when running a large apt-get upgrade set
reev has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
IgorPec has quit [Ping timeout: 264 seconds]
jernej has quit [Ping timeout: 250 seconds]
IgorPec9 has joined #linux-sunxi
mossroy has joined #linux-sunxi
<montjoie>
wens: I will remove thoses messages and for TX FIFO full I will tune it (number of descriptors)
reinforce has joined #linux-sunxi
<Amit_T>
montjoie : Hello, In this sun8i_emac_set_macaddr , you are using only this SUN8I_EMAC_MACADDR_HI register but 32 bits should be stored in SUN8I_EMAC_MACADDR_LO ?
<montjoie>
Amit_T: oooh you are right, thanks
<Amit_T>
ok Thanks for looking in to it.
<wens>
seems like a typo
<montjoie>
but it explains why I needed to tweek the filter
<wens>
also getting RE-RUN RX DMA sometimes
<wens>
overflow?
cosm_ has joined #linux-sunxi
IgorPec9 has quit [Ping timeout: 252 seconds]
<montjoie>
yes
<montjoie>
your version havec only 16 descriptors, it is too few
<montjoie>
I currently read all ethernet driver and they all use more than that
IgorPec has joined #linux-sunxi
yann|work has quit [Ping timeout: 276 seconds]
IgorPec2 has joined #linux-sunxi
IgorPec has quit [Ping timeout: 244 seconds]
<montjoie>
wens: reading documentation said that I need to stop txqueue if the number of free descriptors is below MAX_SKB_FRAGS(16). So a nbdesc of 16 is really too low:)
<wens>
lol
<montjoie>
forcedepth use 64 for TX and 128 for RX
cosm_ has quit [Quit: Leaving]
Netlynx has joined #linux-sunxi
andoma_ is now known as andoma
yann|work has joined #linux-sunxi
paulk-collins has joined #linux-sunxi
speakman has quit [Remote host closed the connection]
speakman has joined #linux-sunxi
bomboletta has joined #linux-sunxi
Jacmet has quit [Ping timeout: 240 seconds]
Jacmet has joined #linux-sunxi
bomboletta has quit [Ping timeout: 248 seconds]
ricardocrudo has joined #linux-sunxi
<wens>
montjoie: anything preventing you from increasing the number?
<zkirill>
what’s the audio driver on A20 called? AC’97?
<wens>
sun4i-codec
matthias_bgg has joined #linux-sunxi
<zkirill>
wens: thank you! :)
<montjoie>
wens: I have increse the number to 64
<montjoie>
wens: and soon I will bench for finding the right number to use
<ssvb>
jernej: both uImage and zImage should work fine, uImage just adds an extra header with a checksum which is kinda nice if you want to safeguard against transmission errors or other sources of data corruption
<jernej>
ssvb: thanks for explanation. What about different loading addresses?
<ssvb>
jernej: zImage is position independent, uimage is probably not so much
<montjoie>
so using zImage could help, but why I get bad CRC
<montjoie>
nobody use opipc with mainline here ? and can report that I am alone
<tkaiser>
montjoie: Data corruption? SD card gone bad?
<ssvb>
montjoie: buggy software or unreliable hardware?
<jelle>
montjoie: I do
<jelle>
I just get: *** Warning - bad CRC, using default environment
<montjoie>
the device works fine with FEL, but I will try another SD
<jelle>
just booted 4.5.0-rc6+ fine
<ssvb>
montjoie: in theory, FEL boot is not exactly the same as SD card boot because the BROM may initialize the hardware in a slightly different way
<ssvb>
montjoie: for example, vishnup encountered some PLL setup problems in the past on A83, where things worked in FEL mode but not from the SD card
<ssvb>
montjoie: in FEL mode, the BROM obviously takes care of initializing whatever is required for a working USB OTG hardware
<montjoie>
ok
<jelle>
silly question then, I'm working on support for hdmi output for the orange pi pc in u-boot. Can you then start u-boot over FEL mode?
<lennyraposo>
building rootfs
<jelle>
now I'm just dd'ing, and swapping sd cards
<ssvb>
once you have DRAM support in U-Boot, you don't need swapping the SD card anymore for doing development
<ssvb>
but in the end after everything is done, the SD boot has to be tested too
<ssvb>
because there can be always some subtle differences
<NiteHawk>
ssvb: what's needed to take your A64 WiP branch of sunxi-tools forward, especially the SRAM restructuring and readl/writel support? do you intend to do a v2 any time soon?
<ssvb>
NiteHawk: yes, sorry about the delay
<NiteHawk>
ssvb: no problem
steeve has joined #linux-sunxi
steeve has quit [Remote host closed the connection]
ricardocrudo has quit [Read error: No route to host]
tkaiser has quit [Ping timeout: 260 seconds]
massi has quit [Quit: Leaving]
alain_ has joined #linux-sunxi
<ssvb>
U-Boot is doing a good job detecting this problem and complaining loudly instead of just trying to run a corrupted kernel
tkaiser has joined #linux-sunxi
<alain_>
montjoie: hi, any updates to the emac driver worth testing on the OPI Plus?
<montjoie>
alain_: no sorry
paulk-collins has joined #linux-sunxi
<alain_>
no worries :) this is the last piece holding me on the crappy 3.4.39 kernel
zkirill has joined #linux-sunxi
<ssvb>
alain_: if you are talking about h3, then proper cpufreq with working budget cooling is still missing too
<ssvb>
otherwise there is a risk of overheating the cpu dangerously
<tkaiser>
ssvb: Could this be adressed from u-boot by eg. choosing just 816 MHz?
<alain_>
ssvb: the poor thing has already been running for 6 months with the crazy overvolting provided by default, not sure how much worse this would be
<alain_>
I actually applied tkaiser's script to take it back to saner defaults yesterday (thanks !!)
<ssvb>
tkaiser: yes, unless we find a way of stressing it too much at 816MHz too
<ssvb>
alain_: one thing is unreasonable default with working protection measures (killing cpu cores, dropping the clock speed)
<ssvb>
alain_: and another thing is just somewhat more reasonable settings but without any temperature monitoring and protection at all
<alain_>
hmmm I understand, good point, thanks for bringing it to my attention :)
al1o has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<tkaiser>
alain_: Settings were developed by ssvb so thank him :)
<alain_>
I kind of assumed the protections were provided by the CPU itself, not by the kernel
<ssvb>
tkaiser: and people may always put their h3 board in a poorly ventilated enclosure, we should never underestimate the users
<tkaiser>
ssvb: LOL, that's true. But how should they know?
<KotCzarny>
make the kernel print big red warnings on core kill/throttle ?
al1o has joined #linux-sunxi
<tkaiser>
ssvb: To my surprise applying a heatsink in a very small enclosure without any ventilation made already a big difference (tested with A64, to be confirmed with other SoCs but I would assume it's identical)
<alain_>
what's a reasonable temperature for H3 ?
<alain_>
mine was hovering at 70+
<KotCzarny>
mine hovers around 37C at idle
<tkaiser>
alain_: 105¡C when doing intensive number crunching ;)
<alain_>
hmmm mine is at 58 now
<KotCzarny>
(opipc)
<tkaiser>
alain_f: Most important lesson regarding numbers: They might be wrong!
<alain_>
OPI Plus with heatsink but in an enclosure
<KotCzarny>
no heatsink, no enclosure
<alain_>
funny enough it never killed cores
<alain_>
just complained
<tkaiser>
KotCzarny: Relying on a thermal sensor that has been added to A20 by accident and is uncalibrated anyway: So in reality it might be 75¡C or 20¡C -- you simply trust in numbers ;)
<KotCzarny>
tkaiser: can touch it, it's mildly warm
<KotCzarny>
58 would be HOT
<KotCzarny>
let me grab infra thermometer
<tkaiser>
alain_: Do you use a Xunlong or loboris image?
<alain_>
loboris
<KotCzarny>
tkaiser, ir thermo says ~37C when near soc and ~32C near drams
<tkaiser>
alain_: His settings don't kill cores, just constant overvolting/overheating :)
<KotCzarny>
cpuburn is already the newest version.
<KotCzarny>
hrm
<KotCzarny>
what is the binary name?
<alain_>
whoops :)
<KotCzarny>
tried loading one core with dd, sysfs says ~45C ir thermo confirms
<tkaiser>
KotCzarny: I don't care about real temperature measurements. I'm just amused how people always trust in numbers. There's a sensor that produces some readouts, then there's a driver trying to interpret these and then there's a frontend trying to display these values
<KotCzarny>
tkaiser, anyway, it seems to be showing real temp
<tkaiser>
And we had situations with A20 and mainline kernel with SoC temperatures below ambient temperature or even below 0¡C. And still people trusted these numbers
<KotCzarny>
so WFM
tomboy64 has quit [Ping timeout: 244 seconds]
tomboy64 has joined #linux-sunxi
IgorPec has quit [Ping timeout: 246 seconds]
cosm has quit [Quit: Leaving]
cosm has joined #linux-sunxi
doppo has quit [Ping timeout: 246 seconds]
doppo has joined #linux-sunxi
marble_visions has joined #linux-sunxi
<tkaiser>
longsleep: In case you've one of these SanDisk Extreme Plus in one of your Pine64 inserted I would still be happy seeing iozone results :)
<marble_visions>
hi all, chapter 12 in the a13 user manual says "The interrupt source 0 is always located at FIQ. The interrupt sources 1 to 63 are located at System Interrupt and user peripheral.", but in reality it's a plain IRQ until you set the correct bit in the interrupt controller
<marble_visions>
then what does it mean "always located at FIQ"?
<marble_visions>
NiteHawk: I know what FIQs are, I don't get what "always located at FIQ" means
<marble_visions>
I assumed that the interrupt controller after power on routed line 0 to fiq, but that's not the case
ricardocrudo has joined #linux-sunxi
doppo has quit [Ping timeout: 246 seconds]
<NiteHawk>
i interpret "always located at FIQ" as: any attempt to set source 0 to "IRQ" (via Interrupt Select Register 0) will be ignored
khuey|away is now known as khuey
doppo has joined #linux-sunxi
<marble_visions>
NiteHawk: but after boot, all irq lines (including 0) are set to normal IRQs.. only after I manually set bit 0 of Select Register 0 to 1 line 0 becomes a FIQ
* marble_visions
is using vanilla linux-sunxi kernel 3.4.104+
<NiteHawk>
marble_visions: what exactly are you referring to by "line 0"?
zuikis has left #linux-sunxi [#linux-sunxi]
<marble_visions>
External NMI
<NiteHawk>
so "source" 0 / SRC 0
<marble_visions>
yes, source 0
<marble_visions>
when i dump the Interrupt Select Register 0, source 0 is a normal IRQ, not a FIQ
<marble_visions>
after boot with no intervention
<marble_visions>
I can toggle it (IRQ/FIQ) and it works both ways
<marble_visions>
as intended
<marble_visions>
i only don't get why they've put "always located at FIQ" since it's not
<NiteHawk>
ISR0 defaults to 0 - are you sure it's treated as IRQ? i suspect that bit 0 is simply ignored
<marble_visions>
i am 90% certain -- it goes through the all the functions a normal interrupt does
<marble_visions>
also, if I loop forever in another interrupt, my FIQ handler doesn't get called
<marble_visions>
(otherwize it would have panic-ed and dumper info on screen)
<marble_visions>
actually that's the giveaway, i've got different things in the FIQ and IRQ handlers so I can see which one gets called
<NiteHawk>
i see. the A10 user manual documents the same "The interrupt source 0 is always located at FIQ." for External NMI. Maybe that's simply inaccurate?
<marble_visions>
either that or they're trying to say something that's true, but we can't understand what
tkaiser has quit [Ping timeout: 246 seconds]
<marble_visions>
does the manual say you need to use their reference linux for the information inside to be correct?
<marble_visions>
because their github repo has another way of registering source 0 and it might be true for that code that source 0 is a FIQ
<NiteHawk>
i don't see a notion of that - it's close to the start of the "interrupt controller" section, right after a rather general description/overview. i'd also expect this to be pretty much "hardware"-related, and not a software- or even os-specific thing
<NiteHawk>
it's seems a bit weird that a "non-maskable" interrupt won't get priority over others (with a lesser priority)
<marble_visions>
it does.. you can't even set an IRQ priority on src 0 (1:0 bits are marked as / in the Source Priority Register 0), which is in line with their view
pmattern has joined #linux-sunxi
tkaiser has joined #linux-sunxi
<marble_visions>
do you know the name of the interrupt controller in the a13? i can't seem to google it
<NiteHawk>
no idea, sorry.
doppo has quit [Ping timeout: 246 seconds]
doppo has joined #linux-sunxi
<marble_visions>
np
avph has quit [Ping timeout: 246 seconds]
iamfrankenstein1 has joined #linux-sunxi
iamfrankenstein has quit [Ping timeout: 248 seconds]