torkell: (Default)
Anyway, enough ranting about nutters on the road. Remember the file uploader I hacked together earlier this year? Well, I discovered a slight flaw when using it with the Wii U - the filename provided by the console is static, and so later uploads overwrite earlier ones. That's easily fixed...

PHP! )

The change is only a few lines - the call to move_uploaded_file has been replaced with

      $pathinfo = pathinfo($_FILES['file']['name'][$i]);
      $dest = $pathinfo['filename'] . strftime('-%Y%m%d-%H%M%S.') . $pathinfo['extension'];
      move_uploaded_file($_FILES['file']['tmp_name'][$i], $dest);


The result is each uploaded file has the current date and time appended to it (for example, vorpal.jpeg becomes vorpal-20141120-205045.jpeg). Obviously this will still overwrite files if you manage to upload the same filename multiple times within the same second, to which my answer is meh! As before, feel free to use it under the 3-clause BSD license.
torkell: (Default)
What to have at the end of a long driving lesson (write-up to follow):



As an aside, because getting photos off of the 3DS is such a kerfuffle (exit game, switch off 3DS, remove memory card and stick in card reader, find .JPG, find corresponding .MPO, persuade Semagic to use the .MPO) I bashed out a noddy little file browser/uploader to stick on the NAS. The Internet is full of all-singing, all-dancing PHP file managers but seems to have a lack of simple little ones that just give a file list and an upload box. All in all, it took me under an hour using nothing more than notepad to write 80-odd lines of PHP that can display a file list, browse and create subdirectories, and upload files.

Edit: fixed unclosed <LABEL> tag and added HTML 5 doctype.

The script itself )

It's been quite some time since I just sat down and bashed out a little program like that for myself. I hadn't realised quite how much I'd missed that sort of quick coding to make things just that little bit more convenient to use.
torkell: (Default)
Right, let's have another crack at that NAS.

Last time I'd come up with a hypothesis for why [livejournal.com profile] pleaseremove's HomePortal software was so slow on my NAS (namely, that PHP was spending most of its time just parsing the source files) and had attempted to prove this by installing the "official" Zend OPcache for PHP. Compiling it then failed because (as best as I can tell) it doesn't actually support the version of PHP on the NAS, despite what the documentation says. So let's have a go with something else...

The Alternative PHP Cache )
torkell: (Default)
Right, so last time I'd successfully installed a profiler and produced an output file. Let's take a look...

Taking a look... )
torkell: (Default)
The story so far: trying to make PHP run faster on a ReadyNAS Duo. Now, when it comes to optimising software there's two rules:

1. Don't optimise

2. Don't optimise yet

What this really means is that you shouldn't just blindly attempt to optimise your code without first knowing which parts of it are actually slow. For example, you may have some function that when you look at the source code is obviously very slow, but in practice it may always be called in a way that means it runs quickly (for example, a bubble sort which only ever sorts 3 items). On the other hand, you might have an algorithm that is usually fast but you just happen to use it in such a way that makes it very slow (for example, a hash map where every element has the same hash code).

Successfully (!) installing Xdebug on a ReadyNAS )
torkell: (Default)
I've given up on the previous NAS - trying to put together a toolchain is proving to be too much hassle, and while I could blow away the custom firmware and put a stock Debian install on it the internets suggest that the Debian kernel doesn't support DMA at which point your performance drops through the floor. Plus it has a dead hard disk and a noisy fan.

So over Christmas I picked up my dad's other old NAS, a Netgear ReadyNAS Duo v1. Like the Thecus it's also Debian-based, but Netgear are running a real full-fat Debian install. And they provide an official addon to enable root SSH access at which point I can log in, download Debian's already-built toolchain, and use that. Simples!

Plus it also has two working hard disks and a much quieter fan :)

Making PHP and mod_rewrite behave )

Next challenge: trying to wring more performance out of PHP! It's a bit sluggish, probably because it only has a 400MHz Sparc processor.
torkell: (Default)
Today's discovery is that a Netgear ReadyNAS Duo, when creating a new user account, "helpfully" emails the new user with their password. This is... undesirable, when the new user account has the same name and password as the one I use on my local computer (because single-sign-on makes everything much nicer to use). This is especially undesirable when the reason my local account is passworded is so that I can safely enable remote access for it.

I suppose it did at least send the email using TLS.

Fortunately it doesn't email when changing passwords. Lesson learnt: create account with dummy password, then set it to super-secret-squirrel password.
torkell: (Default)
Well, I think this explains why one of the drives in the NAS wasn't working...

torkell: (Default)
Part 4a: Successfully building GCC )
torkell: (Default)

So after the epic fail that was the last attempt to build GCC, I did a bit of research into the whole mess. It looks like that to have a reasonable chance of success I *do* need the exact version of GCC that was used.

Warning: much rantage about GCC and Linux linking )
torkell: (Default)

Where was I? Ah yes, building stuff...

Part 2: Building binutils )

Part 3: Kernel and libc headers )
torkell: (Default)

Since getting that NAS, I've been poking around and looking at adding some useful programs to the existing firmware. The initial one I want to run on it is smartmontools, so I can see just what start the hard disks are in and try and prod the second one into actually responding.

As with most embedded stuff, it runs Linux. So getting my own code to run is merely a case of building a cross-compiler that'll run on an actual system and produces output that works on the NAS' armv5l-linux architecture. Actually, since this is a NAS with actual disks I'm not limited to the pokey little flash chip that most embedded stuff has (this device has 16MB of flash - most routers have 8MB or even only 4MB!) and so I could run the compiler on the NAS itself. Unfortunately, it doesn't come with one, and to build a compiler you first need a compiler. Hence the need for a cross-compiler. Since the target is Linux that'd normally mean I'd also need to install a Linux development environment, which I'd rather not have to do - Linux and I don't get on well.

Now, something I tripped across recently is a page on the MinGW website, containing instructions for building a cross-compiler hosted under MinGW. The useful part of this for me is that MinGW along with MSYS is a port of a whole bunch of Linux tools to Windows. So in theory I should be able to use that to build and run my cross-compiler on Windows. This is completely against the normal way of doing things, but the wiki page is proof that it should be possible.

Unfortunately the instructions are rather out of date, so I'm having to make it up as I go along (using a vaguely recent set of instructions for a GNU/Linux ARM toolchain and an older Linux/ARM howto for more recent details). I intend to document this as I go along, partially as a set of notes to myself, partially in the hope that the next person to try this finds it useful, but mainly so you can all point and laugh when it inevitably fails in some spectacular fashion.

Part 1: Installing MinGW )

May 2025

S M T W T F S
    123
45678910
111213141516 17
18192021222324
25262728293031

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jun. 15th, 2025 08:55 pm
Powered by Dreamwidth Studios