08:19 <LunaVorax> Hi

14:05 <apelete> Hello

14:06 <apelete> I have a question for the people who work on the openwrt image for the nanonote

14:06 <apelete> how do you guys debug the uboot bootloader when working on it ?

14:08 <apelete> do you have a jtag accessory or do you use another tool ?

14:30 <xiangfu_> using 'printf' and documents.

14:31 <xiangfu_> and the ingenic released a very old u-boot source code. 1.1.6 IIRC. so we are not start from 0. there are some code that we can look into.

14:38 <apelete> xiangfu_: ok, but what do you do when something goes wrong at uboot level ?

14:39 <apelete> I'm trying to modify the qi uboot to add jffs2 support in addition to ubifs

14:40 <xiangfu_> apelete: I use 'printf' and double check the code.

14:41 <apelete> xiangfu_: you use 'printf' in the uboot code ?

14:41 <xiangfu_> apelete: there is jtag pins in ben nanonte. but I never use that.

14:41 <xiangfu_> apelete: or serial_puts

14:42 <apelete> xiangfu_: my uboot+kernel+image setup does not boot. I'm wondering if I should solder my nanonote to add a jtag/serial debug port

14:42 <xiangfu_> you have to use serial port for sure.

14:42 <xiangfu_> for the kernel output and uboot output.

14:44 <apelete> xiangfu_: I guess I have no other choice then: I will have to solder a serial port on my nanonote...

14:44 <apelete> thanks :)

14:45 <xiangfu_> you are welcome.

14:52 <wpwrak> yeha, jtag is overkill for something like this. i once used it (on gta02, not the ben) to debug an issue in the very first instructions of u-boot, long before it even had the serial port ready. there it was somewhat useful. but that's really a once-in-ten-years sort of situation.

14:55 <apelete> wpwrak: the problem is I don't know another way of debugging early processes like uboot and the kernel

14:56 <apelete> wpwrak: and the ben screen/resolution is way to small to read anything useful when these processes are crashing. do you have any advice ?

14:56 <apelete> s/to small/too small/

14:56 <qi-bot> apelete meant: "wpwrak: and the ben screen/resolution is way too small to read anything useful when these processes are crashing. do you have any advice ?"

14:57 <apelete> (wow, a grammar bot :) )

14:58 <biot> oh my god

14:58 <biot> that's great :-)

14:59 <wpwrak> the screen may not be reliable for such things. what works best is a serial console. that way, you can read the system's last words even if it completely shuts down afterwards.

14:59 <apelete> how do you setup a serial console without a serial/jtag port ?

15:00 <apelete> there is no serial output on the ben by default (hardware wise I mean)

15:00 <wpwrak> here is a drawing of serial debug hardware i once added: http://www.almesberger.net/misc/ben/idbg-v2-install.jpg

15:02 <wpwrak> there is also a second set of contacts but there, the outside->ben direction is shared with another function. here are more details: http://en.qi-hardware.com/wiki/Serial_console

15:10 <apelete> wpwrak: ok, so we're back at the same point: I need to solder a few pins to have a serial console.

15:13 <wpwrak> and something compatible with 3.3 V you can connect to. e.g., another ben or similar. or a RS-232 cable with a level converter, as described in the wiki

15:16 <apelete> wpwrak: thanks for the tips. I was afraid to come down to the soldering iron solution, but I guess I will have no other choice.

15:16 <wpwrak> since your code runs fairly late in the life of the system and crashes may be fairly benign to overall system status (e.g., you're unlikely to disable DRAM refresh or upset address translation), you may also be able to succeed with printing on the screen. if the amount of output is too large, you need to do some limiting. e.g., stop the system after the first error. then you have time to examine the reports, and some of the non-error status output th

15:16 <wpwrak> at may have gone before them.

15:16 <wpwrak> but a serial console is certainly more convenient

17:45 <kristianpaul> wpwrak: abstraction to a higher layer like verilog? or a foorplan description language?

17:58 <wpwrak> oh, just anything above it. typically, it would be a very small abstraction. e.g., if wolfgang uses uint8_t for pin numbers in one and uint16_t in another, then the unifying interface would have uint16_t and maybe check the numbers when going to a uint8_t item.

17:58 <wpwrak> but it would really depend on the nature of the differences

17:59 <wpwrak> i'd assume that xc6 and xc7 are not fundamentally different. i.e., that xc7 still has flip-flops, luts, routes, etc. not, say, descriptions of quantum state.

20:06 <larsc> especially the high level work flows will quite likely be the same

20:06 <Artlav> Hi all.

20:07 <Artlav> Anyone know of an SSTV decoder for NanoNote?

21:00 <wpwrak> Artlav: in my crystal ball, i see one in the future ... one that shall be called Artlav's SSTV decoder :)

21:02 <Artlav> Well, if i get to make one i'll share it. :) Would be a pity to waste the effort if there is one already, however.

21:03 <wpwrak> i wonder if anyone here has ever heard of SSTV before you mentioned it :)

21:05 <wpwrak> perhaps you could adapt QSSTV (or take the parts you can use, and transplant them onto SDL)

21:28 <Artlav> Sounds like a nice use for the nn - put it next to the receiver instead of a bulky laptop, and watch the pictures.