<lekernel>
complement **the set of functions related to file systems offered by the standard Lua distribution**.
<lekernel>
imo you already have everything you need for DMX in that standard distribution
<guyzmo>
lekernel - and do you have a rtfm to write well formatted DMX datagrams into the matching chardev ?
<lekernel>
you don't have to format the DMX frames, the hardware does it for you
<lekernel>
all you need to do is:
<lekernel>
1) open /dev/dmx_out
<lekernel>
2) seek to the channel you want (first position = channel 1, etc. by default the /dev file is opened at channel 1)
<lekernel>
3) write one byte to set the level of that channel - if you write more than one byte it will also assign to the next channels
<lekernel>
4) close /dev/dmx_out
<guyzmo>
interesting implementation
<guyzmo>
it sends the packet on flush() ?
<lekernel>
no, it sends the packet all the time with the memorized channel values
<guyzmo>
ok
<lekernel>
it's like a DMX desk, and using /dev/dmx_out you touch the faders :-)
<guyzmo>
ok, I'll get two DMX projectors for thursday and tomorrow I'll write a demo in lua
<guyzmo>
(I don't have a DMX projector at the bear's cave)
<carlobar>
lekernel: hi, i have made some changes on the hpdmc controller: on initialization i configure burst_length = 2, and now i made 32 bit read/write operations using burst, so i think that im ensuring a data flow during the burst length, but it still dont work. I dont know what else can i do, i dont know what is missing. any advice? thanks
<lekernel>
based on this scarce information, i'd advise you to buy a M1 which i've spent a year or so to get the SDRAM to work on
<lekernel>
have you run verilog simulations first, though?
<carlobar>
hahaha, yes, in simulation it read and write without problem
<lekernel>
including through the l2 cache?
<carlobar>
what is the l2 cache? simulation includes: csrbrg, fmlbrg, hpdmc, ddr... buffers, double date rate flip flops  and the dcm_sp are simulated too. the problem that i had with IDDR2 and ODDR2 was solved adding a flip flop to each one, with that the behavior of these devices was achieved
<carlobar>
on spartan3, ODDR2 and IDDR2 can only be implemented with the parameter: DDR_ALIGNMENT = "NONE", so adding a flip flop, the behavior of DDR_ALIGNMENT = "C0" is achieved
<lekernel>
l2 cache is fmlbrg
<carlobar>
i remember that i had changed the fmlbrg, i had modified it to support fml with 32bit data bus, and i wasnt sure if it worked or not, so i changed it. the fmlbrg uses a state machine to control when an instruction is sent to the fml bus, and when a result is sent to the wishbone bus...
<carlobar>
these are the results when i write/read data:
<carlobar>
mr 0x40000000 16:: 0x40000000Â Â fa de 2b ad 00 00 00 00 00 00 00 00 00 00 00 00Â Â ..+.............
<carlobar>
mr 0x40002000 16:: 0x40002000Â Â fa de 2b ad 00 00 00 00 00 00 00 00 00 00 00 00Â Â ..+.............
<carlobar>
mw 0x40002000 0xabcdef00
<carlobar>
mr 0x40002000 16:: 0x40002000Â Â ab cd ef 00 00 00 00 00 00 00 00 00 00 00 00 00Â Â ................
<carlobar>
mr 0x40000000 16:: 0x40000000Â Â ab cd ef 00 00 00 00 00 00 00 00 00 00 00 00 00Â Â ................
<carlobar>
i thought that the memory didnt recognize the bank or row address, so i made tests changing the bank address, and write/read operations worked...
<carlobar>
im runing the system at a freq of 40MHz, so i modified the timing register
<lekernel>
did you disable the dll in the dram chip?
<carlobar>
you mean the "operating mode" at mode register?
<lekernel>
something like that
<carlobar>
it is in normal operation: 00000..... on the initialization sequence i just modified the burst length
<carlobar>
and added the instructions to change the timing register
<carlobar>
lekernel: do you spent one year working only on SDRAM or you were working in all the system?
<lekernel>
only on SDRAM. but those were in the ML401 days, and I didn't have as much insight into digital design as I have now.
<lekernel>
the M1 just uses roughly the same memory as the ML401 so I did not have to redesign that part
<carlobar>
i just realized that the problem is in directions: 0x40000000, 0x40002000, 0x40004000 and so on.., but sometimes when i read at that directions, previous data is replaced with 0x00000000
<mwalle>
gdb patch is upstream and will be included in gdb 7.3
<lekernel>
the break problem? great :)
<mwalle>
yep
<mwalle>
and there will be target dependent linking for qemu, eg link only to libGL if target==lm32, so it will be enabled by default again