2019-10-20

<libv> naobsd.
<karlp> what's naobsd up to these days?
<libv> H2 2011 and H1 2012 i was on actual android devices, and i counted myself lucky when naobsd threw some binaries together for the m701-r telechips tablet that was a horrible original ipad ripoff

2018-02-02

<wens> naobsd: see the pictures in the later half of https://gnn.gamer.com.tw/4/153434.html
<wens> naobsd: the super famicom board seems to be different than the famicom?

2017-01-26

<naobsd> MoeIcenowy: I'm not sure these updates are useful for you, just FYI...
<naobsd> MoeIcenowy: there are few updates in official up-to-date tree https://github.com/rockchip-linux/kernel/commits/release-4.4/drivers/net/wireless/rockchip_wlan/esp8089
<naobsd> MoeIcenowy: I noticed esp8089 driver is based on old Rockchip SDK
<naobsd> MoeIcenowy: ping

2017-01-01

<ssvb> I think it was naobsd who created it - https://irclog.whitequark.org/linux-sunxi/search?q=naobsd

2016-12-19

<MoeIcenowy> naobsd reads out the value via fel

2016-12-01

<wens> naobsd: it says 'conductive adhesive', where can i get those? :p
<naobsd> I got permission to use that photo on wiki, I'll update page later
<apritzel> naobsd: nice one!

2016-11-30

<naobsd> http://honeylab.hatenablog.jp/entry/2016/12/01/081842 PF0-5 on NES classic, awesome :)

2016-11-19

<ssvb> naobsd: and you may also consider to add A33 support to https://github.com/linux-sunxi/sunxi-tools/blob/master/meminfo.c
<ssvb> naobsd: you can read the DRAM clock speed from the relevant PLL config registers after the DRAM is initialized

2016-11-18

<naobsd> 1.2G/600M should be ok for now ;)
<naobsd> for now I want to know which freq should be written on wiki...
<naobsd> probably stable freq need to be tested with some boards
<naobsd> is max 552MHz in this case?
<naobsd> but
<naobsd> about cpu/dram freq on NES classic,

2016-11-16

<naobsd> Famicom(JP) ver. doesn't have it :(
<naobsd> btw, I noticed NES (US) ver. should have LED... right?
<naobsd> I'll submit this version soon
<naobsd> mripard: thanks
<mripard> naobsd: ^
<naobsd> I'm trying to prepare initial patch for u-boot
<naobsd> if cdc ether and netconsole work, it's nice for NES classic ;)
<mripard> naobsd: it is, but it's slightly hackish
<naobsd> is cdc ethernet not supported on mainline u-boot (sunxi musb)?
<naobsd> hmm

2016-11-15

<naobsd> oops
<naobsd> "./sunxi-fel read 0x42400000 0x82d0 boot1.header" didn't work
<naobsd> http://linux-sunxi.org/Retrieving_device_information#Retrieving_data_over_USB_in_FEL_mode "./sunxi-fel read 0x43000000 0x20000 script.bin" this works
<naobsd> (RESET button method and send '2' method don't run boot1, DRAM is not initialized)
<naobsd> if you send 's' to UART, yes
<naobsd> I'll try later
<naobsd> ssvb: I never tried that method
<ssvb> naobsd: I mean, if you enter the FEL mode after turning the device off and waiting some tens of seconds, is the script.bin data there?
<naobsd> send 's' to UART -> run 'fastboot' -> FEL mode with DRAM data
<ssvb> naobsd: I see, and was it so that you read the leftover data in DRAM after resetting the device when running the stock firmware?
<naobsd> ssvb: update sunxi-tools... sunxi-fel read 0x43000000 0x10000 script.bin is fine
<ssvb> naobsd: so which steps were needed to extract the script.bin data?
<naobsd> MMC need to be disabled to boot properly...
<naobsd> power is lost, of course ;)
<naobsd> I pulled USB cable after running fel uboot
<naobsd> I was thinkig that use OTG as HOST
<naobsd> oops
<naobsd> I see
<wens> naobsd: given that sunxi u-boot is currently in limbo, i can't say for sure :|
<naobsd> wens: http://git.denx.de/?p=u-boot/u-boot-sunxi.git;a=shortlog;h=refs/heads/next this should be used for base?
<wens> naobsd: it's a mirror of the sunxi custodian repository
<naobsd> u-boot-sunxi mirror/next is for upstreaming, right?
<naobsd> sys_config/a33? or sys_config/r16?
<naobsd> I know what should be done, what I don't know well is about A33 ;)
<naobsd> yes of course
<naobsd> machine = "parrot" lol
<naobsd> is last E: ok?
<naobsd> fexc-bin: script.bin: version: 1.2 fexc-bin: script.bin: size: 131072 (78 sections), header value: 41936 E: fexc-bin: script.bin: empty entry in section: csi0
<naobsd> mmm it's updated a little...anyway thanks
<naobsd> works now :(
<naobsd> grrrr
<naobsd> it should be new...
<naobsd> E: fexc-bin: Malformed data: version 41936.1.2.
<naobsd> but bin2fex didn't work...
<naobsd> yeah, many params are follow,
<MoeIcenowy> naobsd: I think it's a script.bin.
<naobsd> it might be better to build modified u-boot :(
<naobsd> 00000000 4e 00 00 00 d0 a3 00 00 01 00 00 00 02 00 00 00 |N...............| 00000010 70 72 6f 64 75 63 74 00 00 00 00 00 00 00 00 00 |product.........|
<naobsd> 0x43000000 doesn't have valid header :(
<naobsd> anyway, what I want to do is collection info
<naobsd> are regulator settings right?
<naobsd> compatible = "allwinner,parrot",
<naobsd> I know mainline spl works, how to build spl
<naobsd> well
<naobsd> where is common location for script.bin on A33 devices?
<naobsd> well, my current goal is adding very very initial support ;)
<naobsd> for u-boot I should get regulator info?
<naobsd> but u-boot/kernel is still stock, very restricted
<naobsd> for now, temporary (not soldered ;)
<naobsd> these values are same as parrot R16
<naobsd> enough?: CONFIG_DRAM_CLK=600 CONFIG_DRAM_ZQ=15291 CONFIG_ODT_EN=y
<MoeIcenowy> naobsd: U-Boot SPL uses only a few parameters
<naobsd> (looking info in NAND...)
<naobsd> is it enough for u-boot spl?
<naobsd> I can see some DRAM info on console http://linux-sunxi.org/Nintendo_NES_Classic_Edition#Stock_U-Boot
<naobsd> about NES classic, currently I cannot get info by thins way

2016-11-12

<zerotri> Naobsd: able to pull things from NAND but still no luck getting console in Linux
<naobsd> zerotri: I noticed you also saw things in NAND
<naobsd> well, more accurately, "analysis for mainline"
<naobsd> I heard it can be built, but I didn't try. my interest is mainline.
<naobsd> zerotri: are you asking binary, not source, right?
<zerotri> naobsd: did you have any luck getting the nintendo released uboot built or are you trying with mainline only?

2016-11-11

<naobsd> MoeIcenowy: could you tell me detail about it?
<naobsd> what's 'something' for A33/R16?
<naobsd> but I heard that it's not enough for A33/R16, something in firmware image or on shell on running device is required.
<naobsd> about NES classic, it should be able to get DRAM param and script.bin now(not yet tried),
<naobsd> well, 2 more R16 SID...useless?
<naobsd> so no need to ask 2 friends?
<MoeIcenowy> naobsd: we should not only rely on NES classic
<naobsd> MoeIcenowy: I'm asking 2 friends (they have NES classic)
<naobsd> btw is there any difference between A33 and R16?
<naobsd> MoeIcenowy: yes
<MoeIcenowy> naobsd: can I add your SID to http://linux-sunxi.org/index.php?title=SID_Register_Guide ?
<naobsd> MoeIcenowy: 0461872a:86583185:9ae7d847:6c118000
<naobsd> ah 'sid' command
<naobsd> sunxi-fel cannot be used for it?
<naobsd> ah well
<MoeIcenowy> naobsd: if you can provide one
<naobsd> is R16 SID needed?
<naobsd> I'll try, but I'm busy, anyone can do it too :)
<naobsd> I'll try rest too :)
<naobsd> yes I know, at least u-boot spl is working
<MoeIcenowy> naobsd: you can try to run mainline u-boot/linux on it
<naobsd> what I want to try is, mainline u-boot/linux, *BSD, etc. not dumping NAND
<naobsd> anyway,
<naobsd> but I believe it's possible now
<naobsd> not yet
<naobsd> important part should be protected properly
<naobsd> majosa: I hope so
<naobsd> (except script.bin)
<naobsd> I will not do/put information such as dumping NAND, analyzing its contents, etc
<MoeIcenowy> naobsd: I think you shoudn't
<naobsd> should I remove wiki?
<MoeIcenowy> naobsd: I think a mainline kernel can now run with USB gadget as I/O device
<naobsd> all I want to try is, just run our own u-boot/linux/etc on it
<naobsd> I never do it
<naobsd> stock u-boot can read NAND of course, so now I worry about Nintendo
<naobsd> as I said, problem is solved by using stock u-boot
<naobsd> well
<MoeIcenowy> naobsd: as I say
<naobsd> DRAM should be able to read in this case
<naobsd> stop autoboot by 's', then run "fastboot" on u-boot, then fel can be used
<naobsd> ah, good news
<naobsd> let's try...
<naobsd> is A33 NAND driver available on mainline u-boot/linux?
<naobsd> probably I can ignore information in NAND (for a while)
<naobsd> so
<naobsd> no hang
<naobsd> I can read 0xff from 0x43000000
<naobsd> it works
<naobsd> sunxi-fel spl u-boot-sunxi-mainline-sinlinx_sina33-20160902T174215-b615267/u-boot-sunxi-with-spl.bin
<naobsd> 20160902 binary is enough new?
<naobsd> I see
<naobsd> oops, u-boot-sunxi nightly latest for a33 is not built... (err)
<naobsd> DRAM access hangs both 'press & hold RESET' / 'send 2 to UART' method :(
<naobsd> ssvb: DRAM can be read w/o boot0/1(i.e. FEL mode just after BROM)?
<naobsd> what I expect is, boot1 does something, then read dram via fel
<ssvb> naobsd: just reading DRAM will not do anything good for you, unless something reads the FEX file into it
<naobsd> or felix does better?
<naobsd> should I try mainline u-boot with spl (for another a33 board)...?
<naobsd> send '1' to UART is not working (normal boot), I have no idea to init dram
<naobsd> wens: I don't know why :(
<wens> naobsd: then dram init is not working
<naobsd> only DRAM area cannot be accessed :(
<naobsd> I can read sram and some registers area, so fel is working properly
<naobsd> same result with '2' method :(
<naobsd> I have to try another method :( probably send '2' to UART is needed
<naobsd> so
<naobsd> this is what I got...
<naobsd> about sunxi-fel on A33, DRAM should work w/o any preparation?
<naobsd> I should check console if init dram is ok or fail...
<naobsd> write fes1.bin to 0x2000 then exe 0x2000, but read 0x43000000 is still failed :(
<naobsd> if I try "sunxi-fel read 0x43000000 0x1000 xxx" then device stop working (probably... no console access for now)
<naobsd> MoeIcenowy: could you tell me which part of image?
<naobsd> MoeIcenowy: you said using fel is not enough and image is required,
<naobsd> MoeIcenowy: about getting information from A33 device,
<naobsd> wiki need to be fixed ;)
<naobsd> I just noticed there is description about compatible controller on NES Classic official page...
<naobsd> oops
<MoeIcenowy> naobsd: so thanks
<naobsd> hm... all I know should be dumped to wiki. the remaining is for everyone :)
<naobsd> MoeIcenowy: not yet for me. I just heard about it from other people. command is very limited (please refer u-boot source for detail)
<MoeIcenowy> naobsd: you can stop autoboot?!

2016-11-10

<apritzel> naobsd: thanks!
<NiteHawk> naobsd: very nice
<MoeIcenowy> naobsd: congrats
<naobsd> NES Classic UART pins are confirmed, GND TX RX (from left to right)
<naobsd> ah, then NES classic is _the 1st_ w/SLC? ;)
<bbrezillon> naobsd: the good news is that it's an SLC NAND ;)
<naobsd> bbrezillon: thanks :)
<bbrezillon> naobsd: see this patch series => https://www.mail-archive.com/u-boot@lists.denx.de/msg230192.html
<bbrezillon> naobsd: you should be able to flash a bootable SPL and uboot image in NAND
<naobsd> (and generally I don't have so much time for this... I just wanted to know about FEL/UART for now)
<naobsd> yeah I should it, but sorry, I had no time, no picture myself yet
<tkaiser> naobsd: Process is outlined here: http://linux-sunxi.org/New_Device_page#Starting_point
<tkaiser> naobsd: In case you're taking pictures and collect some stuff already, this page here is for you: http://linux-sunxi.org/index.php?title=Nintendo_NES_Classic&action=edit
<naobsd> I didn't read carefully, sorry
<naobsd> ah thanks
<tkaiser> naobsd: Also the Link to Olimex' github repo before was there for a reason, they have an A33 board with NAND and combine mainline u-boot with smelly 3.4 kernel
<tkaiser> naobsd: It should work since NextThing is doing exactly this on their CHIP
<naobsd> (reading wiki again...)
<naobsd> thought
<naobsd> what I though is "using fel mode _everytime_" is not so handy...
<naobsd> well, if otg host mode is supported on u-boot, "support NAND _on u-boot_" might not be needed
<naobsd> ah
<tkaiser> naobsd: bbrezillon should know?
<naobsd> is mainline u-boot can be flashed on NAND?
<naobsd> ah yes clovercon
<naobsd> so available interface should be: OTG HDMI(via bridge) UART and I2C
<naobsd> it seems controller interface is i2c. I don't know detail but someone said it should be same as Wii classic controller
<naobsd> btw I don't know any other game except "find FEL/UART!" yet :)
<naobsd> please check official info
<naobsd> OTG is exposed. near to HDMI. JP model and US?WW? model is different form, but USB/HDMI interface should be same
<tkaiser> naobsd: Is OTG exposed externally or do you have to open the box?
<naobsd> then I disassembled it for "find UART!" game. but I had no time to reassemble it, I couldn't bright it to home ;)
<naobsd> I had to play "find FEL!" game at work place :)
<naobsd> hehe. Nintendo Classic Mini was released today @JP, I bought it on the way of home -> work
<wens> apritzel: maybe naobsd works at nintendo? :p
<apritzel> naobsd: shouldn't it be the other way round (game console at home)? ;-)
<naobsd> I hope someone might try soon ;)
<naobsd> I cannot try it now (my NES classic is at work place... I'm at home now)
<naobsd> it's worth a try :)
<MoeIcenowy> naobsd: maybe
<naobsd> firmware.img for another A33 device might be enough to dump partition...?
<naobsd> https://github.com/lolet/FELix#howtos hmm firmware.img is required...
<MoeIcenowy> naobsd: you can try https://github.com/lolet/FELix
<naobsd> hmm
<naobsd> is there any way to run or flash costomized _Allwinner_ kernel via fel mode?
<naobsd> there is no network/external storage on NES classic. if update image will be available in future, it will be flashable image via OTG (just my guessing)
<naobsd> I guess shell is not running on console... I have to solder TX/RX pad (not yet for now)
<naobsd> shell under BSP? root shell on console?
<MoeIcenowy> naobsd: a Pheonix image or a interactive shell under BSP
<naobsd> what's required for A33?
<naobsd> oops
<MoeIcenowy> naobsd: nope it's not enough.
<wens> naobsd: u-boot and boot0 blobs have a header section, where some parameters get written too
<naobsd> so fel mode is enough? :)
<naobsd> ./sunxi-fel read 0x43000000 0x20000 script.bin
<naobsd> ah
<wens> naobsd: afaik the fex file contains the customizations
<MoeIcenowy> naobsd: yes
<naobsd> well, I should read wiki at first ;)
<naobsd> I guess boot0 is common for all board with same SoC, right?
<wens> naobsd: nope, that's a separate thing, which they aren't bound to release
<MoeIcenowy> naobsd: nope, but A33 lichee have boot0 source
<naobsd> I'm not sure u-boot source includes boot0
<wens> naobsd: you need boot0, u-boot first
<naobsd> it may be possible that run modified Allwinner kernel(w/ NAND support) from fel?
<naobsd> currently I have no idea to get fex from running device
<naobsd> as I posted kernel has no output. I never tried UART RX yet, I'm not sure shell is running or not (I guess not) so
<MoeIcenowy> naobsd: where did you get it
<naobsd> wens: thanks
<wens> naobsd: the fex file is in a separate directory outside of u-boot/linux
<naobsd> there is kernel/u-boot source for NES Classic, but I cannot remember where fex should be stored...
<naobsd> I cannot remember detail... is allwinner u-boot uses fex(.bin)? or pin configuration should be described in u-boot source tree?

2015-10-17

<BorgCuba> I think I could ask naobsd from linux-rockchip if he joins on #linux-rockchip

2014-12-08

<naobsd> sorry, it might be a17
<naobsd> I saw matt does something
<naobsd> ah
<naobsd> how about smp on a80?
<naobsd> a lot of commits in source-changes :)
<naobsd> btw there is #linux-rockchip for rockchip ;)
<naobsd> tokuda-san and I am very busy... no or very few progess :(
<naobsd> hi
<jmcneill> hi naobsd

2014-11-10

<naobsd> I'm not sure it's xhci compatible, need to check linux code...
<naobsd> ah
<naobsd> sounds good :)
<naobsd> who has a80 board? matt?
<naobsd> hm
<naobsd> I should setup my Allwinner boards :)
<naobsd> well
<naobsd> jmcneill: which u-boot are you using? upstream? github/linux-sunxi?
<naobsd> jmcneill: I guess u-boot knows proper ram size...?
<naobsd> jmcneill: oh...
<naobsd> jmcneill: btw, board specific kernel config is not mandatory now by fex support? my understanding is bit old
<naobsd> jmcneill: sorry, I just asked whole NetBSD, not /evbarm or you :)
<naobsd> jmcneill: is there any plan to support device tree in NetBSD?
<naobsd> jmcneill: it seems some part is hardcoded or specified by kernel config
<naobsd> I'll try on my A20 Lime
<naobsd> really great

2014-11-08

<naobsd> there is "#ifdef CONFIG_MACH_SUN6I", A31 is sun6i
<naobsd> jmcneill: 2nd patch has "Major cleanups and some small bugfixes" "sun6i-hdmi-hack"
<jmcneill> naobsd: that uboot patch should be very helpful, thank you!
<naobsd> http://lists.denx.de/pipermail/u-boot/2014-August/185193.html display support in u-boot might be helpful?
<naobsd> jmcneill: ah, you already wrote awin_hdmi.c, you should know these docs, sorry...
<naobsd> jmcneill: I'm not sure but information may be available here: https://github.com/allwinner-zh/documents
<naobsd> ah, I'm just chatting, don't be serious ;)
<naobsd> oh