<tkaiser>
jelle: If you play around with SD card and eMMC on the Air then better start to explore referencing devices by UUID and not device node (we switched to UUIDs in Armbian some months ago to avoid all those hassles with different device enumeration)
<MoeIcenowy>
but EOMA68 guys seems to ignored something
<KotCzarny>
remember article is from july
<MoeIcenowy>
for example, most things in Qualcomm 410's boot sequence is closed source -- only the APPBL part is open (equal to U-Boot or Little Kernel)
<KotCzarny>
MoeIcenowy: read the last paragraph, its explained there
<MoeIcenowy>
and many Atoms come with AXP288 ;-)
chomwitt has joined #linux-sunxi
Worf has quit [Quit: Konversation terminated!]
paulk-blaze has quit [Quit: Leaving]
Stoned0651 has joined #linux-sunxi
<jelle>
tkaiser: ahh thanks for the info
<jelle>
tkaiser: I roll my own distro (arch) :)
reev has quit [Ping timeout: 258 seconds]
<tkaiser>
jelle: I know. But that doesn't matter. You can adopt UUID changes to boot.cmd and /etc/fstab there too ;) And it might be interesting that you then also can directly flash an image to eMMC (or check Armbian's nand-sata-install.sh script above how to transfer an image from SD card to eMMC without any hassles)
<jelle>
tkaiser: yup
* jelle
is aware how UUID works :)
Mr__Anderson1 has joined #linux-sunxi
Mr__Anderson has quit [Remote host closed the connection]
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
fkluknav has joined #linux-sunxi
yann-kaelig has joined #linux-sunxi
afaerber has joined #linux-sunxi
<MoeIcenowy>
seems that for UUID to work an initrd is needed...
<rah>
KotCzarny: if you don't know, you can't help me :-)
<KotCzarny>
k, not bothering you again
<rah>
thank you
yann-kaelig has quit [Ping timeout: 240 seconds]
ErwinH has joined #linux-sunxi
BenG83 has quit [Quit: Leaving]
ErwinH has quit [Ping timeout: 245 seconds]
ErwinH has joined #linux-sunxi
ixnus has quit [Ping timeout: 260 seconds]
tobiasBora has quit [Quit: Kthxbye]
IgorPec5 has quit [Ping timeout: 264 seconds]
ErwinH has quit [Ping timeout: 240 seconds]
ErwinH has joined #linux-sunxi
wzyy2 has joined #linux-sunxi
vishnup has joined #linux-sunxi
ErwinH has quit [Ping timeout: 240 seconds]
ErwinH has joined #linux-sunxi
ErwinH has quit [Ping timeout: 240 seconds]
BenG83 has joined #linux-sunxi
ErwinH has joined #linux-sunxi
ErwinH has quit [Ping timeout: 240 seconds]
ErwinH has joined #linux-sunxi
ErwinH has quit [Ping timeout: 240 seconds]
ErwinH has joined #linux-sunxi
ErwinH has quit [Ping timeout: 245 seconds]
LargePrime has joined #linux-sunxi
ErwinH has joined #linux-sunxi
<plaes>
rah: what bug?
Leepty has quit [Quit: Leaving]
ErwinH has quit [Ping timeout: 256 seconds]
LargePrime has quit [Ping timeout: 255 seconds]
ErwinH has joined #linux-sunxi
paulk-collins has joined #linux-sunxi
chomwitt has quit [Ping timeout: 240 seconds]
ErwinH has quit [Ping timeout: 276 seconds]
fkluknav has quit [Ping timeout: 255 seconds]
ErwinH has joined #linux-sunxi
LargePrime has joined #linux-sunxi
ErwinH has quit [Ping timeout: 276 seconds]
ErwinH has joined #linux-sunxi
ErwinH has quit [Ping timeout: 260 seconds]
zoobab has joined #linux-sunxi
wzyy2 has quit [Read error: Connection reset by peer]
ErwinH has joined #linux-sunxi
ErwinH has quit [Ping timeout: 245 seconds]
LargePrime has quit [Ping timeout: 240 seconds]
ErwinH has joined #linux-sunxi
victhor has joined #linux-sunxi
ErwinH has quit [Ping timeout: 260 seconds]
ErwinH has joined #linux-sunxi
Andy-D has joined #linux-sunxi
ErwinH has quit [Ping timeout: 240 seconds]
LargePrime has joined #linux-sunxi
cobra_koral has quit [Ping timeout: 264 seconds]
ErwinH has joined #linux-sunxi
ErwinH has quit [Ping timeout: 240 seconds]
<ElBarto>
wens: so on clkng for A31 you have spdif defined despite being not present in the docs
<ElBarto>
wens: is this a left over from h3 or spdif is really present on A31 ?
<MoeIcenowy>
ElBarto: I think SPDIF do exist
<MoeIcenowy>
there's someone that have sent out a patch for one A31 device with SPDIF
ErwinH has joined #linux-sunxi
<ElBarto>
MoeIcenowy: I know the docs are wrong on a lot of stuff, just want to be sure that this is intentional and not a copy paste error :)
Amit_T_ has joined #linux-sunxi
<MoeIcenowy>
oh the device is Mele I7
<MoeIcenowy>
arch/arm/boot/dts/sun6i-a31-i7.dts
<ElBarto>
since I'm currently doing clkng for FreeBSD I'm looking at linux driver for the clock names and I've stumbled into this
<MoeIcenowy>
ElBarto: you may directly need Linux's include/dt-bindings/{clock,reset}/sun*i-*.h
<ElBarto>
I've rewritten those (because of reasons), but this doesn't give me the names
LargePrime has quit [Ping timeout: 256 seconds]
<MoeIcenowy>
but you must keep the relationship of numbers and clocks
ErwinH has quit [Ping timeout: 240 seconds]
<MoeIcenowy>
otherwise DT will be not compatible
<ElBarto>
yes I know
<MoeIcenowy>
P.S. I think you can ask Maxime Ripard to add MIT license to the files
<ElBarto>
things are more complicated than that
<ElBarto>
even if it shouldn't be :)
<ElBarto>
and this is not really long/hard to rewrite the files, it's just boring :P
<swabbles>
ssvb: how long does u-boot ML moderation usually take?
<ssvb>
swabbles: moderation?
<mripard>
ElBarto: I wonder how you could argue that it's not derivative work though :)
<swabbles>
"Your message to U-Boot awaits moderator approval."
<ssvb>
swabbles: have you subscribed to u-boot the mailing list before posting patches?
<swabbles>
yes, I have.
<ElBarto>
mripard: it definitivly is (I think), I'm not a lawyer
<ssvb>
hmm, that's strange
<swabbles>
First time, I tried (before subscribing) I got another reason (not being subscribed).
<ElBarto>
mripard: but what do you want us to do ? patch the DTS ? do our own ? we've been there, no thanks
<swabbles>
Then I tried after subscribing, and it tells me that it is a moderated list.
<mripard>
ElBarto: if it is derivative, then it is under the GPL
<swabbles>
But I have been awaiting approval for two hours or so.
<ssvb>
swabbles: but you can probably go to the #u-boot channel and ping some people there, it might help
<swabbles>
Thanks, will do.
<ElBarto>
mripard: but is it really ?
<ElBarto>
mripard: you've come up with IDs and we've took the same to be compatible
<mripard>
the proper solution would be to ask the author if he'd like to relicense under a BSD-like license, and use that header directly
<mripard>
but you're basically just changing the license without the author consent
<mripard>
which is bad
<mripard>
I am ok with relicensing, I don't know about wens
<ElBarto>
well not really because I didn't use the same name (but they are similar)
<ElBarto>
but this raise the question about MIT dts compiled with GPL headers ...
<ElBarto>
mripard: I'm up for doing the right thing, so if you want me to send you an email (should a list be cc'ed ?) asking you to relicence I'll do it
<mripard>
You can send a patch to the headers authors, changing the license to a dual GPL/BSD
<mripard>
we did it in the past for the DTS, and it went well, so it shouldn't be very touchy
<mripard>
especially if you have a real argument for it
<mripard>
(which you do)
<ElBarto>
eh, just looked at the files, it's already dual licenced :P
<ElBarto>
so I'll just check with FreeBSD Core Team which file I should use etc ... (my patch is in review for now)
|Jeroen| has joined #linux-sunxi
LargePrime has joined #linux-sunxi
matthias_bgg has quit [Quit: Leaving]
LargePrime has quit [Ping timeout: 240 seconds]
LargePrime has joined #linux-sunxi
Putti has joined #linux-sunxi
<Putti>
sunxi-fel on debian gives "usb_bulk_send() ERROR -7: Operation timed out" – any ideas for fixing? Looked online a bit for solutions. Should I increase the timeout interval or is there some other underlying problem?
<Putti>
(increasing the timeout interval would mean compiling fel tool from source, I think
reinforce has joined #linux-sunxi
<KotCzarny>
try resetting (power cycling) the board, for my laptop and opipc i usually can get fel ver then one or two bigger commands, then often something hangs and ends with send errors
<Putti>
KotCzarny, ok, thanks
<KotCzarny>
but your case might be different, still, if you can get it working after power cycle and failing after some commands then it might be similar
<Putti>
yeah, tried now twice to poweroff and it didn't work
ErwinH has joined #linux-sunxi
<KotCzarny>
not even 'ver' command?
<Putti>
the ver works
<Putti>
but sunxi-fel uboot u-boot-sunxi-with-spl.bin doesn't
<rah>
MoeIcenowy: I modified the kernel command line so that it outputs console messages to the virtual console
<rah>
MoeIcenowy: there is console output but it stops half-way through booting and the monitor goes to "No Signal", long before X runs
<Putti>
I will get the sunxi-fel source and will try increasing the timeout
<ssvb>
when you start a wrong bootloader binary, the processor just deadlocks and that's why you get this "usb_bulk_send() ERROR -7: Operation timed out" error (the device just stops talking back)
<KotCzarny>
anyway, i have this ebook reader what is the way to reset it to try running sd-fel card? i cant see reboot command anywhere in ui
<Putti>
ssvb, ok, so let me try another configuration
<KotCzarny>
or the disconnecting battery is the only way?
<Putti>
(for u-boot)
<ssvb>
btw, did the "sunxi-fel uboot u-boot-sunxi-with-spl.bin" command itself fail with this error?
<Putti>
yes
<ssvb>
ok, because this command starts u-boot, and the device is not expected to talk FEL after that (so any subsequent FEL commands will fail)
<ssvb>
but if the "sunxi-fel uboot" command itself failed, then this usually indicates that u-boot has died
<Putti>
right, but "usb_bulk_send() ERROR -7: Operation timed out" should not come still?
<Putti>
ok
jernej has quit [Quit: Konversation terminated!]
<ssvb>
which defconfig are you using now?
<Putti>
q8_a33_tablet_800x480_defconfig
<Putti>
didn't even check if my resolution is that...
<Putti>
I should probably :)
<Putti>
it is
<Putti>
With that defconfig it didn't work, same error
<Putti>
I will try now manually tweaking it
<ssvb>
so you are running "sunxi-fel ver" and it works fine, then you are running "sunxi-fel uboot u-boot-sunxi-with-spl.bin" and if fails?
<Putti>
correct
netlynx has quit [Quit: Ex-Chat]
<ssvb>
can you run "sunxi-fel -v uboot u-boot-sunxi-with-spl.bin" and pastebin its output?
<Putti>
ok
<Putti>
mhm, I will reset the device first
<mripard>
rah: please send an email with what you're seeing, with which kernel version and on what board
<Putti>
I haven't got yet around using the longer timeout as there seems to be some problem with missing libusb.h header file
<ssvb>
Putti: yeah, it starts the SPL, but then it fails to transfer and start the main U-Boot part
<rah>
mripard: ok
<Putti>
ssvb, so it is not even about the wrong u-boot image, right?
<ssvb>
Putti: the longer timeout will not help, your problem is that the SPL unexpectedly dies
<Putti>
ok
<ssvb>
which U-Boot version is that?
LargePrime has joined #linux-sunxi
<ssvb>
you can try a few older releases just to see if this helps
<Putti>
latest from git
Nemo_bis has joined #linux-sunxi
<Putti>
ssvb but if it doesn't even start the transfer?
<ssvb>
try some release tags tags
<ssvb>
if the device does not want to talk back, then it's impossible to transfer anything there
chomwitt has joined #linux-sunxi
ErwinH has joined #linux-sunxi
<Putti>
bbiab
<ssvb>
normally people debug such problems using the UART serial console, but you probably don't have any access to it
<Putti>
I tried to have access via micro sd card breakout board but I think my wires are too loose or something as I didn't get any TX signal from the tablet
<Putti>
or maybe I put the wires to wrong places
<Putti>
Will check in a bit
<ssvb>
not even any kind of garbage (when the boot ROM is probing the MMC boot)?
<ssvb>
so I would not rule out generic reliability problems with your board
<ssvb>
that's why exact steps to reproduce it would be very much welcome
massi has quit [Remote host closed the connection]
<KotCzarny>
ssvb, what i still remember was that i could be sending repeated ver commands as much as i want, but doing anything bigger was failing intermittently
florianH has quit [Quit: Connection closed for inactivity]
<Putti>
back, I will try now the serial console again
<ssvb>
KotCzarny: as I said, please try to reproduce it again and submit a formal bugreport with all the exact steps
<ssvb>
KotCzarny: if I can reproduce it, then I might be able to debug it
<ssvb>
KotCzarny: if not, then you can try a bit more conservative DRAM and CPU clock speed settings just to see if that helps
<KotCzarny>
will try to make a test case when i get around it again
<ssvb>
thanks!
<ssvb>
Putti: please first try some older stable U-Boot releases instead of the current git master branch
<KotCzarny>
drat. i broke ereader case while trying to open. eh
<Putti>
ssvb, alright, haha, and now realized I had put one TX wire to wrong place, so maybe that's why nothing came out :)
<Putti>
let's try again now
<ssvb>
Putti: you should get at least a line of junk printed on the serial console after reset, this happens because the boot ROM is trying to boot from MMC
<Putti>
ok
<ssvb>
and if everything is connected correctly, you still need to enable a special option CONFIG_UART0_PORT_F=y when building U-Boot in order to redirect the serial console output
<Putti>
right, so I cannot use it even now (or I might hope the factory has enabled that)
<Putti>
but nothing so far
<ssvb>
frankly speaking, I used this option a very long time ago (after actually fixing it!), so something might have bitrotten since then
vagrantc has joined #linux-sunxi
tsuggs has joined #linux-sunxi
Ntemis has joined #linux-sunxi
* Putti
got some UART serial console garbage!
<Putti>
though not sure if it is because I broke something
<Putti>
but I have > there
<KotCzarny>
oh wow, some f*cktard glued the battery to the backcase o.O
<Putti>
Is ">" something you others have gotten too
<KotCzarny>
> is probably uboot prompt
<Putti>
cool!
<KotCzarny>
try entering help<enter>
<Putti>
ton of stuff came about kernel booting!
<Putti>
ok this is working now!
<Putti>
ssvb, KotCzarny thanks !
solarnetone has joined #linux-sunxi
<KotCzarny>
i havent done anything :)
afaerber has quit [Quit: Leaving]
<Putti>
you helped me earlier :)
<KotCzarny>
oh, anyway, have a fun with your toy
<ssvb>
hmm, what about the "usb_bulk_send() ERROR -7: Operation timed out" error? has it disappeared?
<Putti>
ssvb, not that far yet
<ssvb>
are you getting all these messages from the stock firmware now?
<Putti>
yes, It booted to the Android OS it had, I will now try booting again to FEL mode
ErwinH has joined #linux-sunxi
solarnetone has quit [Read error: No route to host]
terra854 has quit [Quit: Connection closed for inactivity]
<KotCzarny>
hmm, funny, no battery connector, so if system hangs how do i reset a13 board?
<KotCzarny>
(no battery connector == battery wires soldered)
<Putti>
KotCzarny, reset in which sense?
ErwinH has quit [Ping timeout: 256 seconds]
<KotCzarny>
reset in a sense of restart or powercycle
<Putti>
it doesn't have power button?
<KotCzarny>
what if it hangs in uboot for example? or with kernel panic?
<Putti>
mhm, let's see if a13 manual says something about resetting
<beeble>
KotCzarny: short pin 25 on axp209 to gnd
<KotCzarny>
beeble, that tip should go into wiki!
<KotCzarny>
is pin 24 a ground or i have to find it somewhere else?
ErwinH has joined #linux-sunxi
afaerber has joined #linux-sunxi
<beeble>
KotCzarny: also if the axp is configured the right way pressing the power button long should turn it off
<KotCzarny>
oh, nice
<beeble>
that would also result in a rest when powered on again
<KotCzarny>
'powered on' as in reapplying power or just pressing power button?
<beeble>
pressing power again
<beeble>
next to 25 is not gnd. but there should be some bypass caps around with gnd on one side
<beeble>
there should also be a pull up on the trace from axp pin 25 to the cpu. so if you want to build your own reset key you cant attach there easily
<beeble>
if there isn't already some test pads
ErwinH has quit [Ping timeout: 255 seconds]
<beeble>
at least i would build a device like that for development and production
ixnus has joined #linux-sunxi
<KotCzarny>
those pins are tiny, let's hope pwr key trick will be enough
<beeble>
now you see what i have to deal with daily :)
<KotCzarny>
at least you have experience on your side
<ixnus>
KotCzarny: hm, that delivery was quick. Can you please put the device on the wiki , whenever you wish.
<KotCzarny>
ixnus: just started opening it, it's not very diy friendly (already managed to damage the front bezel, but it's open now)
<ixnus>
yeah, good luck hacking on it !
<beeble>
KotCzarny: you should press at least 6 seconds. and if you build your own uboot check that you don't write bad values to reg 36
<KotCzarny>
o.O
<beeble>
bit 3 to be specific
<beeble>
that would turn off that power down feature by long press
<KotCzarny>
is it sticky?
<KotCzarny>
ie. once written it would be remembered
<beeble>
it's volatile. but you would have to disconnect the battery
<beeble>
or reset via pon 25
<beeble>
pin
<KotCzarny>
uhum
<KotCzarny>
btw. was that autotranslated or something? 'Key long when you grew up in the shutdown automatic shutdown feature set '
<beeble>
welcome to english allwinner documents :)
<beeble>
the formating is better if aw dies the translating then sending it through google translate yourself
ixnus has quit [Ping timeout: 260 seconds]
<beeble>
*does
boycottg00gle has quit [Remote host closed the connection]
Amit_T_ has quit [Remote host closed the connection]