scream has quit [Remote host closed the connection]
egbert has joined #linux-sunxi
egbert_ has quit [Ping timeout: 246 seconds]
ninolein has quit [Ping timeout: 245 seconds]
ninolein has joined #linux-sunxi
Andy-D has quit [Ping timeout: 260 seconds]
orly_owl_ has joined #linux-sunxi
orly_owl has quit [Ping timeout: 252 seconds]
deskwizard has quit [Read error: Connection reset by peer]
orly_owl_ has quit [Quit: leaving]
pg12_ has quit [Ping timeout: 268 seconds]
pg12 has joined #linux-sunxi
victhor has quit [Ping timeout: 260 seconds]
lkcl has quit [Ping timeout: 245 seconds]
terra854 has joined #linux-sunxi
perr has quit [Quit: Leaving]
p_rossak has quit [Quit: No Ping reply in 180 seconds.]
longsleep has quit [Quit: No Ping reply in 180 seconds.]
longsleep has joined #linux-sunxi
p_rossak has joined #linux-sunxi
MXfive has joined #linux-sunxi
TheSeven has quit [Ping timeout: 240 seconds]
TheSeven has joined #linux-sunxi
leviathanch has joined #linux-sunxi
MXfive has quit [Quit: Sleep Quit.]
Wizzup has quit [Ping timeout: 245 seconds]
leviathanch has quit [Remote host closed the connection]
leviathanch has joined #linux-sunxi
fdcx_ has joined #linux-sunxi
fdcx has quit [Ping timeout: 258 seconds]
<habs>
dgp: hi, so I've spent a lot of time trying to understand the sunxi tools and I've outlined my train of thought in this shell script: http://sprunge.us/OIIT?sh
<habs>
but there are some holes, notably the "???" line in that script which I believe is wrong
<habs>
I was wondering if you or anyone else can help me understand what to do with the script.bin file once I make it? specifically how to build, send, and boot the kernel on the device?
<ssvb>
that's an ancient kernel branch, which was only used for a10/a13/a20
<ssvb>
also script.bin and device tree are mutually exclusive things (different implementations of the same idea)
<ssvb>
btw, why don't you just buy one of the modern allwinner devboards? you will get a much beefier hardware for less money, and also will not have to "jailbreak" it
<ssvb>
my understanding is that the lion's share of the Nintendo NES Classic Edition price is their bundled software
<ssvb>
but if you don't want their software, then what's the whole point?
<KotCzarny>
ssvb: nice box, gamepad ports and gamepads ?
<ssvb>
what is gamepad?
<KotCzarny>
controller
<ssvb>
is it connected to USB?
<KotCzarny>
i think they use i2c
<ssvb>
weird
<ssvb>
but if somebody is a gamer, why not to use USB or wireless controllers from some other consoles?
<KotCzarny>
dont ask me, they probably chose that for compatibility reasons/lower cost
<habs>
ssvb: Thanks for the help, but my understanding is that the nes classic board isn't yet supported in device tree, so I'll have to use the older kernel?
<ssvb>
afaik nobody maintains older kernel for a33
<habs>
ssvb: I'm just having a lot of trouble interpreting this page -- the fact that it only provides a .fex file indicates that the page author intends for me to use an old kernel version, right? http://linux-sunxi.org/Nintendo_NES_Classic_Edition
<ssvb>
this page seems to be some work-in-progress experiment
<habs>
ssvb: Yes, thanks for the link. I'm just having trouble understanding the utility / purpose of a script.bin file? If it isn't used at all in the kernel compilation, then when is it used? the "Install script.bin
<habs>
" section on the wiki page still says "todo" unfortunately
<ssvb>
script.bin is a hardware configuration description
<ssvb>
the idea is that exactly the same kernel can run on different boards, while just using different configs
f0xx has quit [Ping timeout: 252 seconds]
<KotCzarny>
in mainline it was rewritten into dts/dtb
<ssvb>
the sun8i-a33-sinlinx-sina33.dtb file serves roughly the same role for the 4.x mainline kernels
<habs>
ssvb: ah, and I see someone on reddit has slightly modified that dts file to work with the NES, so maybe that new dts file could be submitted as a patch to sunxi-next?
<habs>
or would that be sunxi-devel
LargePrime has quit [Ping timeout: 258 seconds]
<habs>
So using that patch to sun8i-a33-sinlinx-sina33.dtb I think I understand how to build the sunxi-next kernel now, but how can I send it to the actual NES?
<habs>
If I try to run "./sunxi-tools/sunxi-fel uboot ./u-boot/u-boot-sunxi-with-spl.bin write 0x42000000 ./linux-sunxi/arch/arm/boot/zImage write 0x46000000 ./linux-sunxi/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dtb" I just get "ERROR: Attempt to overwrite U-Boot!" and then booting via serial doesn't seem to do anything...
bonbons has joined #linux-sunxi
MXfive has quit [Quit: Sleep Quit.]
reinforce has joined #linux-sunxi
Wizzup has joined #linux-sunxi
MXfive has joined #linux-sunxi
<KotCzarny>
yay, i got the first edit in 2017
corecode has quit [Ping timeout: 260 seconds]
f0xx has joined #linux-sunxi
<ssvb>
habs: it just means that you got the addresses wrong
<ssvb>
unless there is some regression in sunxi-fel
<freemangordon>
habs: and in boot.cmd: bootz 0x46000000 - 0x49000000
netlynx has joined #linux-sunxi
<NiteHawk>
ssvb: BTW, what about the plan to eventually make those "hardcoded" addresses from U-Boot available via the sunxi header? is that still on your agenda?
vinidev has joined #linux-sunxi
|Jeroen| has joined #linux-sunxi
<ssvb>
NiteHawk: I'm not super active in the sunxi stuff anymore
<ssvb>
but my plan was to eventually try to move to DFU
<ssvb>
but for this to work, we need much better USB OTG support for sunxi boards in U-Boot
victhor has joined #linux-sunxi
<ssvb>
and considering that board maintainers are generally doing a sloppy job (at least with the DRAM config/reliability), I don't have very high expectations from them on the USB front either :-)
<NiteHawk>
:) i see.
<ssvb>
I'm also not sure if runtime detection of the device/host mode is supported by the USB OTG driver in U-Boot, probably need to check it again
<NiteHawk>
a basic approach could be to save the "magic" constants that U-Boot uses (${kernel_addr_r} and the like) in the mksunxiboot header, so that user's won't have to give them explicitly to sunxi-fel. we could then introduce "write" aliases that imply a certain load address ("kernel", "dtb", "script" commands)
<KotCzarny>
imo having good docs/howtos would be better
<ssvb>
we already have docs/howtos
<KotCzarny>
and just add more verbose help to tools
<KotCzarny>
yes, but not in the tool itself
<NiteHawk>
KotCzarny: that doesn't save you from having to adjust your stuff if u-boot decides to change the address layout - we currently simply don't have that info readily available (to us = sunxi-fel)
<ssvb>
NiteHawk: yes, we can have these values in the SPL header, but the DFU protocol already takes care of defining and communicating the information about these areas over USB
<KotCzarny>
that assumes having online connection, which is usally avAilable, but sometimes not
<ssvb>
with DFU we can also get much faster transfer speeds
<ssvb>
because FEL is restricted to just using the 12 Mbit mode and it is slow
LargePrime has joined #linux-sunxi
<ssvb>
NiteHawk: the next step could be adding the DFU capability bit to the SPL header and set it for the boards which already have usable USB OTG support
<ssvb>
then the sunxi-fel tool could check this bit and automatically switch to the DFU mode
<ssvb>
we would need a few more commands, so it becomes a little bit complicated
<ssvb>
though I believe that the majority of users already can use FEL boot successfully and problems are uncommon
<ssvb>
habs is just one of the rare exceptions
<ssvb>
mostly because the Nintendo NES Classic Edition support is in a poor shape in general
leviathanch has quit [Remote host closed the connection]
iamfrankenstein has quit [Ping timeout: 252 seconds]
iamfrankenstein1 is now known as iamfrankenstein
pg12 has quit [Ping timeout: 258 seconds]
pg12 has joined #linux-sunxi
corecode has joined #linux-sunxi
jernej has joined #linux-sunxi
jernej has quit [Ping timeout: 260 seconds]
mzki has quit [Ping timeout: 248 seconds]
corecode has quit [Ping timeout: 258 seconds]
rookieone has quit [Ping timeout: 258 seconds]
mzki has joined #linux-sunxi
MXfive has quit [Quit: Sleep Quit.]
utente_ has quit [Ping timeout: 265 seconds]
corecode has joined #linux-sunxi
corecode has quit [Ping timeout: 258 seconds]
pg12 has quit [Ping timeout: 265 seconds]
pg12 has joined #linux-sunxi
corecode2 has joined #linux-sunxi
corecode has joined #linux-sunxi
utente_ has joined #linux-sunxi
avph has quit [Ping timeout: 260 seconds]
corecode has quit [Ping timeout: 260 seconds]
corecode2 has quit [Read error: Connection reset by peer]
avph has joined #linux-sunxi
corecode has joined #linux-sunxi
corecode2 has joined #linux-sunxi
<habs>
freemangordon: Thanks so much for the help. If I try to execute a command with your memory addresses though, I still get "ERROR: Attempt to overwrite U-Boot!", here is the full output: http://sprunge.us/RXWV?l
<habs>
and this shows up on the serial console at the same time if it helps: http://sprunge.us/hTAS
corecode has quit [Ping timeout: 260 seconds]
corecode has joined #linux-sunxi
<habs>
and here is my updated list of commands I've performed if that helps: http://sprunge.us/DaMS?sh
<habs>
notably my addresses are now "sudo ./sunxi-tools/sunxi-fel -v -p uboot ./u-boot/u-boot-sunxi-with-spl.bin write 0x46000000 ./linux/arch/arm/boot/zImage write 0x49000000 ./linux/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dtb write 0x43100000 ./u-boot/boot.scr"
corecode has quit [Read error: Connection reset by peer]
corecode has joined #linux-sunxi
terra854 has quit [Quit: Connection closed for inactivity]
corecode has quit [Read error: Connection reset by peer]
xes has quit [Read error: Connection reset by peer]
Pepe has joined #linux-sunxi
vagrantc has joined #linux-sunxi
vinidev has joined #linux-sunxi
utente__ has joined #linux-sunxi
utente_ has quit [Ping timeout: 245 seconds]
<NiteHawk>
habs: your zImages seems a bit weird: it has an apparent size of ~168MiB. loading those 176,230,832 bytes at address 0x46000000 would extend up to 0x508111B0, and thus overwrite U-Boot (and also collide with the DTB)
<NiteHawk>
that's why sunxi-fel complains and prevents you from doing this
<habs>
NiteHawk: OK thanks, do you think that could be because my rootfs is too big? Or some other reason?
corecode2 has quit [Quit: ERC (IRC client for Emacs 24.5.1)]
<habs>
if so, is there any place to get a generic minimal armhf rootfs so I don't have to re-debootstrap my own?
<NiteHawk>
wait, did you embed an initrd/initramfs into that kernel?
<NiteHawk>
that would explain the file size
<habs>
NiteHawk: yes, I used CONFIG_INITRAMFS_SOURCE="/home/habs/rootfs"
<NiteHawk>
habs: you need to make sure that the memory regions you try to load the various bits and pieces into don't *overlap*, possibly by rearranging their memory layout. one way to achieve that would be to keep the initramfs separate (reducing kernel size) and load it at a different address (avoiding collisions)
<NiteHawk>
i have no experience with loading and starting a kernel that big at a different (higher) memory address (beyond u-boot and dtb). that might work, too
orly_owl has joined #linux-sunxi
Ntemis has joined #linux-sunxi
orly_owl has quit [Quit: leaving]
<habs>
NiteHawk: OK, so I recalculated the start address to be 0x49000000 - 0xA8111B0 ~= 0x3E000000. These are the new commands with that: http://sprunge.us/GhPG?sh
Mr__Anderson has joined #linux-sunxi
<habs>
but now when I run the sunxi-fel command I get "usb_bulk_send() ERROR -7: Operation timed out
<habs>
", at around 12%, both of the two times I try it (full output here http://sprunge.us/AZBA )
deskwizard has joined #linux-sunxi
<habs>
does this mean I have to make a separate initramfs, or is it some other greater problem?
BenG83 has joined #linux-sunxi
<NiteHawk>
habs: you can't use addresses below 0x40000000, which is the start of DRAM on most Allwinner devices
<KotCzarny>
170MB boot via fel? that sure will take a while
<NiteHawk>
if you want to keep your 'monolithic' zImage, try loading somewhere above the end of U-Boot (0x4A05FB2F), e.g. 0x4A100000 - adjusting your "bootz" command accordingly
KB3VGW has joined #linux-sunxi
<NiteHawk>
not sure if that will work out smoothly, but at least worth a try
KB3VGW has left #linux-sunxi [#linux-sunxi]
<NiteHawk>
and yes, you might want to consider alternatives for that big rootfs - e.g. have u-boot load it from other media (sdcard, usb), or use NFS root, or...
<KotCzarny>
(User creation log); 19:57 . . User account NoraZea73641 (Talk | contribs) was created
<KotCzarny>
(diff | hist) . . N User talk:NoraZea73641; 20:08 . . (+174) . . NoraZea73641 (Talk | contribs) (Created page with "I am Werner from Daly City. I am learning to play the Bass Guitar. Other hobbies are Taxidermy.<br><br>Also visit my blog ... [http://huurwoning123.nl/ huurwoningen den haag]")
<KotCzarny>
bass guitar taxidermy
<jelle>
o.O
<NiteHawk>
that's most likely a (spam) bot account
<ssvb>
KotCzarny: you have just helped them to propagate their web page link, now it's in the irc chat log :-)
BenG83 has quit [Quit: Leaving]
<NiteHawk>
nevertheless: thanks for pointing out that user
chomwitt has joined #linux-sunxi
leviathanch has quit [Remote host closed the connection]
jernej has quit [Ping timeout: 258 seconds]
BenG83 has joined #linux-sunxi
<KotCzarny>
ssvb, as long irclogs add rel=nofollow, no harm done
BenG83 has quit [Client Quit]
<willmore>
Obvious spammer is obvious.
f0xx has quit [Ping timeout: 258 seconds]
silviop has joined #linux-sunxi
victhor has joined #linux-sunxi
<silviop>
how is support for csi cam ? I not found how enable gc0309 in mainline kernel
<silviop>
i talk about A13 / A33 tablets
netlynx has quit [Quit: Ex-Chat]
utente__ has quit [Ping timeout: 245 seconds]
vagrantc has quit [Quit: leaving]
iamfrankenstein has quit [Quit: iamfrankenstein]
rookieone has joined #linux-sunxi
utente__ has joined #linux-sunxi
scream has quit [Remote host closed the connection]