Sur d’autres sites (5496)

• Anomalie #3920 (Nouveau) : sur Sauvegarde SQLite (SPIP 3.1.3 et 3.1.4 mini)

  11 mars 2017, par YannX DYX

  En SPIP 3 la sauvegarde standard pose parfois des problèmes, que j’ai trop souvent vus...
  Cette fois j’ai investigué sur un SPIP 3.1.4 OVH (avec prefix spécifique), toutes les tables ne sont pas sauvegardées, au contraire de la sauvegarde SQL : certes un message existe mais !
  - d’une part des tables vides ou non déclarées dans un plugin activé sont omises : pourquoi ?
  (encore une fois au contraire de la sauvegarde SQL encore disponible en plugin !)
  => est-il possible d’apporter un lien vers une aide plus détaillée, explicitant les causes possibles ?
  (cf. http://forum.spip.net/fr_262960.html & http://forum.spip.net/fr_266342.html par exemple).
  - le long libellé affiché <:dump:texte_sauvegarde:> ne signale aucunement ces aspects et indications ; le lien vers http://www.spip.net/fr_article1489.html est-il encore pertinent (je n’ai jamais tenté une restauration d’une autre version SQLite : comment se passerait une table non déclarée ou non connue dans le SPIP cible ? ) ?
  - d’autre part la lecture du message en fin des erreurs est peu explicite à la lecture (cf. ci-dessous),
  il me semblerait plus significatif d’afficher : Nombre de tables non sauvegardées : 12/58
  - d’ailleurs l’affichage est incorrect, car il n’indique pas le bon préfixe (en cas de préfixe non-standard !!)
  (et de ce fait, je vais avouer avoir jusqu’à présent négligé ces erreurs incomprises, et... patatras !)
  _ S’il est intéressant de faire une sauvegarde dé-préfixée (ce que j’ai parfois trouvé utile), peut-etre serait-il intéressant de faire apparaitre (dans un commentaire ou une meta) le préfixe d’origine, à titre de documentation !

  En recherchant de la documentation, je n’ai trouvé que http://www.spip.net/fr_article3418.html qui mériterait peut-etre d’etre complété avec les informations/explications ci-dessus (et leurs conséquences)...

  En complément, le site exemple ayant été migré d’anciennes versions SPIP 2, montre encore les anciennes tables@ spip_mots_xx@
  je ne me souviens pas d’un plugin qui éliminerait ces anciennes tables résiduelles (pour ceux qui ne savent utiliser phpMyAdmin ou Adminer)... ce qui supprimerait ensuite ces erreurs / voir par exemple sur les forums SPIP)

• Hacking the Popcorn Hour C-200

  3 mai 2010, par Mans — Hardware, MIPS

  Update : A new firmware version has been released since the publication of this article. I do not know if the procedure described below will work with the new version.

  The Popcorn Hour C-200 is a Linux-based media player with impressive specifications. At its heart is a Sigma Designs SMP8643 system on chip with a 667MHz MIPS 74Kf as main CPU, several co-processors, and 512MB of DRAM attached. Gigabit Ethernet, SATA, and USB provide connectivity with the world around it. With a modest $299 on the price tag, the temptation to repurpose the unit as a low-power server or cheap development board is hard to resist. This article shows how such a conversion can be achieved.
  

  Kernel

  The PCH runs a patched Linux 2.6.22.19 kernel. A source tarball is available from the manufacturer. This contains the sources with Sigma support patches, Con Kolivas’ patch set (scheduler tweaks), and assorted unrelated changes. Properly split patches are unfortunately not available. I have created a reduced patch against vanilla 2.6.22.19 with only Sigma-specific changes, available here.

  The installed kernel has a number of features disabled, notably PTY support and oprofile. We will use kexec to load a more friendly one.

  As might be expected, the PCH kernel does not have kexec support enabled. It does however, by virtue of using closed-source components, support module loading. This lets us turn kexec into a module and load it. A patch for this is available here. To build the module, apply the patch to the PCH sources and build using this configuration. This will produce two modules, kexec.ko and mips_kexec.ko. No other products of this build will be needed.

  The replacement kernel can be built from the PCH sources or, if one prefers, from vanilla 2.6.22.19 with the Sigma-only patch. For the latter case, this config provides a minimal starting point suitable for NFS-root.

  When configuring the kernel, make sure CONFIG_TANGOX_IGNORE_CMDLINE is enabled. Otherwise the command line will be overridden by a useless one stored in flash. A good command line can be set with CONFIG_CMDLINE (under “Kernel hacking” in menuconfig) or passed from kexec.

  Taking control

  In order to load our kexec module, we must first gain root privileges on the PCH, and here a few features of the system are working to our advantage :

  1. The PCH allows mounting any NFS export to access media files stored there.
  2. There is an HTTP server running. As root.
  3. This HTTP server can be readily instructed to fetch files from an NFS mount.
  4. Files with a name ending in .cgi are executed. As root.

  All we need do to profit from this is place the kexec modules, the kexec userspace tools, and a simple script on an NFS export. Once this is done, and the mount point configured on the PCH, a simple HTTP request will send the old kernel screaming to /dev/null, our shiny new kernel taking its place.

  The rootfs

  A kernel is mostly useless without a root filesystem containing tools and applications. A number of tools for cross-compiling a full system exist, each with its strengths and weaknesses. The only thing to look out for is the version of kernel headers used (usually a linux-headers package). As we will be running an old kernel, chances are the default version is too recent. Other than this, everything should be by the book.

  Assembling the parts

  Having gathered all the pieces, it is now time to assemble the hack. The following steps are suitable for an NFS-root system. Adaptation to a disk-based system is left as an exercise.

  1. Build a rootfs for MIPS 74Kf little endian. Make sure kernel headers used are no more recent than 2.6.22.x. Include a recent version of the kexec userspace tools.
  2. Fetch and unpack the PCH kernel sources.
  3. Apply the modular kexec patch.
  4. Using this config, build the modules and install them as usual to the rootfs. The version string must be 2.6.22.19-19-4.
  5. From either the same kernel sources or plain 2.6.22.19 with Sigma patches, build a vmlinux and (optionally) modules using this config. Modify the compiled-in command line to point to the correct rootfs. Set the version string to something other than in the previous step.
  6. Copy vmlinux to any directory in the rootfs.
  7. Copy kexec.sh and kexec.cgi to the same directory as vmlinux.
  8. Export the rootfs over NFS with full read/write permissions for the PCH.
  9. Power on the PCH, and update to latest firmware.
  10. Configure an NFS mount of the rootfs.
  11. Navigate to the rootfs in the PCH UI. A directory listing of bin, dev, etc. should be displayed.
  12. On the host system, run the kexec.sh script with the target hostname or IP address as argument.
  13. If all goes well, the new kernel will boot and mount the rootfs.

  Serial console

  A serial console is indispensable for solving boot problems. The PCH board has two UART connectors. We will use the one labeled UART0. The pinout is as follows (not standard PC pinout).

          +-----------+
         2| * * * * * |10
         1| * * * * * |9
          -----------+
            J7 UART0
      /---------------------/ board edge
  

  Pin	Function
  1	+5V
  5	Rx
  6	Tx
  10	GND

  The signals are 3.3V so a converter, e.g. MAX202, is required for connecting this to a PC serial port. The default port settings are 115200 bps 8n1.

• Capturing PCM audio data stream into file, and playing stream via ffmpeg, how ?

  11 avril 2015, par icarus74

  Would like to do following four things (separately), and need a bit of help understanding how to approach this,

  1. Dump audio data (from a serial-over-USB port), encoded as PCM, 16-bit, 8kHz, little-endian, into a file (plain binary data dump, not into any container format). Can this approach be used :

     $ cat /dev/ttyUSB0 > somefile.dat

  Can I do a ^C to close the file writing, while the dumping is in progress, as per the above command ?

  2. Stream audio data (same as above described kind), directly into ffmpeg for it to play out ? Like this :

     $ cat /dev/ttyUSB0 | ffmpeg

  or, do I have to specify the device port as a "-source" ? If so, I couldn’t figure out the format.

  Note that, I’ve tried this,

  $ cat /dev/urandom | aplay

  which works as expected, by playing out white-noise..., but trying the following doesn’t help :

  $ cat /dev/ttyUSB1 | aplay -f S16_LE

  Even though, opening /dev/ttyUSB1 using picocom @ 115200bps, 8-bit, no parity, I do see gibbrish, indicating presence of audio data, exactly when I expect.

  3. Use the audio data dumped into the file, use as a source in ffmpeg ? If so how, because so far I get the impression that ffmpeg can read a file in standard containers.

  4. Use pre-recorded audio captured in any format (perhaps .mp3 or .wav) to be streamed by ffmpeg, into /dev/ttyUSB0 device. Should I be using this as a "-sink" parameter, or pipe into it or redirect into it ? Also, is it possible that in 2 terminal windows, I use ffmpeg to capture and transmit audio data from/into same device /dev/ttyUSB0, simultaneously ?

  My knowledge of digital audio recording/processing formats, codecs is somewhat limited, so not sure if what I am trying to do qualifies as working with ’raw’ audio or not ?

  If ffmpeg is unable to do what I am hoping to achieve, could gstreamer be the solution ?

  PS> If anyone thinks that the answer could be improved, please feel free to suggest specific points. Would be happy to add any detail requested, provided I have the information.